Docsapps

Connecting Apps to Workflows

Start workflows from an app with the App trigger, show a workflow's latest result on a page, and choose what the page may read.

An app and a workflow are connected in one of two directions:

The app starts the workflow - a form submission, or a page that runs a workflow on what the visitor enters. The workflow uses an App trigger naming the app.
The app shows the workflow's result - a result page reads the latest completed run of a source workflow, whatever started it (usually a schedule).

The assistant can make either connection for you (Connect a workflow quick start), and can build a missing workflow - see App Assistant.

The App trigger

In the workflow editor, click the Trigger node and set Trigger type to App ("A form, a page or a custom app"). Then:

Select app... - the list shows the apps of the workflow's own workspace (an app only ever starts workflows of its workspace). A draft app is marked (Draft).
The inspector shows the app's App URL and the fields the workflow will receive.
Save the workflow and switch it to Active. An inactive workflow is not started by the app - the inspector warns: "Runs from the app will not start until you switch it to Active."

One app may start several workflows: every active workflow of the workspace whose App trigger names the app runs on each submission. In the other direction, the app editor lists them under Settings > Workflows this app can run.

If a trigger names an app that is in another workspace or was deleted, the inspector says so ("This app is not in this workflow's workspace … it will never start this workflow") and the workflow analysis reports it as critical.

Form trigger (legacy). Workflows that used the old Form trigger were switched to the App trigger with their form app selected. A node still showing Form (legacy) names a form that no longer exists and never starts; click Switch to App trigger and choose the form app.

What the workflow receives

Values arrive under trigger.data:

{
  "appId": "…",
  "appName": "Damage report",
  "submittedAt": "2026-11-03T09:12:00.000Z",
  "submissionId": "…",
  "fields": {
    "order_number": "A-1042",
    "description": "Box crushed on one side",
    "photo": { "name": "box.jpg", "size": 245678, "contentType": "image/jpeg", "key": "…" }
  }
}

Reference	Value
`{{trigger.data.fields.<name>}}`	A field's value (a file field is an object - see Forms & Submissions)
`{{trigger.data.appName}}` / `{{trigger.data.appId}}`	Which app started the run
`{{trigger.data.submittedAt}}`	When the visitor sent it (ISO time)
`{{trigger.data.submissionId}}`	The stored submission (submissions only - not on a plain run)

For a form app, the field names come from Settings > Fields. For other apps the app's own code decides what it sends - the inspector says "fields are defined by the app".

Showing the visitor a result

Starting a workflow from an app comes in two styles:

Fire and forget - the submission is stored, the workflows run in the background, and the visitor sees the success message at once.
Wait for the answer - the app waits for one workflow (the form's Result workflow, or the workflow the page names) and shows its result: the output of the run's last completed step. Design that workflow so its last step returns exactly what the visitor should see, for example a Transform producing { "ticket": "…", "eta": "…" }.

A visitor only ever sees the result of their own run. If a run fails, the visitor sees a generic error message - never the workflow's internal error.

A Dashboard app works the same way without storing a submission: the visitor enters something, the page runs the workflow and shows the answer.

Result pages: the source workflow

A result page shows the latest completed run of its source workflow. Set it in Settings > Source workflow (or let the assistant do it):

"The page shows the latest completed run of this workflow (runs started by apps are never shown)." - a visitor's input never appears for the next visitor.
The page refreshes itself; run the workflow again (by hand, on a schedule or from a webhook) and the page shows the new result.
Give the source workflow a Cron Schedule trigger when the page should stay current on its own - the assistant does this when it builds a source for a result page.
None removes the source.

What the page may read

By default the page gets the output of the source run's last step. "Ask the workflow to prepare the page data in its last step (the assistant does this for you)." That keeps the page simple and the data small.

For a workflow you cannot change, list exactly what the page may read under What the page may read: each row is a name the page uses and a path into the run:

Name	Path
`total`	`steps.summarize.output.total`
`rows`	`steps.fetch.output.items`
`period`	`trigger.data.period`

Only steps.<node>.output[.field] and trigger.data[.field] paths are allowed (up to 20 rows). Add from the last run… suggests node outputs from the source's last completed run. Global variables can never be read by a page.

Refresh and Cache

Setting	Meaning
Refresh	How often an open page re-reads the result: Off or 10–3600 seconds.
Cache (seconds)	How long a public answer may be cached. A password-protected page is never cached.

When a workflow is deleted

Deleting a workflow does not delete the apps connected to it. A result page whose source is gone keeps its address but has nothing to show, and the editor's Source workflow reads "A workflow that no longer exists" until you pick another. A form keeps storing submissions; they are marked "Nothing started" until another workflow is bound.

Triggers - every trigger type
Forms & Submissions
JavaScript API - FlowTrux.run, FlowTrux.result, FlowTrux.latest

← Forms & Submissions Publishing & Access→