Workflow Basics

Workflows run actions when something happens to a form or entry. They can calculate values, update records, send email, generate PDFs, branch on conditions, process lists, and call extensions or API Connectors.

Workflow Structure

Every workflow contains:

• One or more triggers that start the workflow
• Steps that perform work
• Connections that select what runs next

Trigger → Step → Condition ─ true  → Step
                         └ false → Step

Each trigger has a start step. Most steps continue through a next path, while conditions, loops, and extension actions expose additional named paths.

Create a Workflow

1. Open a draft form version in the builder.
2. Select Workflows.
3. Select Create Workflow and give it a clear name.
4. Add a trigger and configure any field or page selectors it needs.
5. Select + Add Step, choose a step, and configure its inputs.
6. Connect the available output paths to the next steps.

Workflow changes save as you edit. Workflows belong to the form version, so publish that draft version when the workflow is ready to become active. Existing entries remain associated with the version under which they were created.

The workflow list is sorted by title and can be filtered by title, ID, trigger, or step type. Open a workflow to rename it from the editor header. Delete removes that workflow from the draft after confirmation; it does not remove historic run records already attached to entries.

Use the Canvas

• Drag the background to pan.
• Scroll or use the controls to zoom.
• Select a node to view or edit its configuration.
• Use a node’s path controls to connect its next step.
• Delete a connection or node when it is no longer needed.

The editor prevents invalid structures such as cycles, self-connections, and placing a For Each step inside another For Each loop. A trigger that is not connected to a start step is shown as incomplete and cannot do useful work.

Connection Paths

For Each labels loop as Loop Body and next as After Loop in the editor.

A failure before a response is received, such as an invalid reference or unreachable service, fails the workflow run immediately. It does not follow an error connection. The Extension Action error path is specifically for an HTTP request that completed with a non-success status.

Execution Timing

Steps run in order until the workflow completes or a step fails. A workflow failure is recorded on its run, while the entry update or submission that triggered it is still allowed to complete.

The Send Email step queues the message for delivery. The workflow can complete once the message is queued, before final delivery is confirmed.

During execution, steps can use:

• Current entry answers, metafields, and metadata
• Entries from other forms
• Data table rows and cells
• Outputs from earlier reachable workflow steps
• The current item and loop-body outputs inside For Each

Use the reference picker instead of typing IDs. See References & Data for the exact stored syntax.

Workflow Runs

Every execution creates a run with a started, completed, or failed state and a step-by-step log.

To inspect a run:

1. Open the entry in the project admin area.
2. Select Workflow Runs.
3. Open a run to inspect the trigger, paths, step inputs and outputs, timing, and errors.

For an API Connector request, the log can include the status, headers, raw response, and parsed response body.

Test a Workflow

There is no separate workflow test runner. Test the real trigger against a draft or test entry:

1. Finish the workflow on the draft form version.
2. Open the draft Preview, which creates ordinary test entries against that draft version.
3. Perform the triggering action.
4. Inspect Workflow Runs on the resulting entry.
5. Publish only after the draft workflow passes its checks.

Use test environments for external services and API Connectors before selecting live credentials.

Good Practices

• Keep one workflow focused on one operational outcome.
• Give steps stable, descriptive IDs because references use those IDs.
• Put a Condition before an action that should only happen for some entries.
• Store durable external IDs or decisions back on the entry; workflow outputs exist only in the current run.
• Check both the completed path and failure cases before publishing changes.