How workflows work

A workflow decides what happens after someone submits your form: send an email, ask for an approval, add a row to a sheet, post in Slack, call a webhook. You draw it as a chain of steps on a canvas, test it, and publish it.

The trigger

Every workflow starts with a trigger. Click it to choose:

• Form submitted (the default) runs when a form is submitted. On a form that takes payment, it runs once the payment is confirmed. When a respondent revises a response (after a send back for changes), the revised response runs the workflows again from the start.
• Form abandoned (Pro) runs when someone fills in part of the form and is inactive for the time you pick, from 30 minutes to 2 days. Use it to remind them with a link that brings their answers back. It needs Save unfinished responses; see Recover unfinished responses.

Steps

Under the trigger, click Add step and pick one. The picker has two groups:

• Integrations: Email, Google Sheets, Slack, Microsoft Teams, SMS, Notion, Airtable, Webhook and Send to app (Zapier, Make, n8n).
• Logic: Condition, Route, Lookup table, Approval (Pro), Send back for changes and Wait.

Click a step to open its settings. Text in a step can include the respondent’s answers and details of the response; see Answers in steps.

Steps run one after the other. When a step fails, the steps after it don’t run, unless you tell one to: open that step, choose Settings, and under Run this step when the previous step pick:

• Succeeds: only when the previous step succeeds (the default).
• Fails: only when the previous step fails, for alerts or fallbacks.
• Always: whether it succeeds or fails.

The canvas marks those steps on failure or always. To branch on the answers themselves, use a Condition or Route.

Wait

A Wait step pauses the run, then continues. Set Wait for (hours), up to 30 days. While it waits, the run shows when it will continue; it resumes within a minute of that time.

Test before you publish

Test (top of the editor) runs your draft against sample answers you type in. No response is recorded, and steps that would send something are mocked: the run shows what they would have sent. Switch a step to Run for real to really send it. A real test email through the built-in sender can only go to your team or a verified address, at most 10 per test. Wait steps are skipped, and an approval can be decided automatically, inline, or for real.

Publish and versions

You always edit a draft. Respondents only ever trigger the published version, so editing a live workflow is safe until you click Publish changes. The dialog lists what will change, and anything that has to be fixed first: a step with no recipient, a question that was deleted from the form, a disconnected app.

Each publish is a version. The publish menu can Discard draft changes or Revert to a version… (which puts that version back in the draft, for you to publish). A run that started on an older version finishes on it. When you retry one, you can choose to continue on the latest version instead; see Runs and fixing failures.

The workflow list shows Unpublished changes when the draft differs from what’s live, and badges for anything that would block publishing.

On, off, and several workflows

A workflow runs only when it’s published and switched on. Switching it off stops it on new submissions; runs already going finish.

A form can have up to 10 workflows. Each one runs on its trigger, independently and in no particular order, so keep steps that depend on each other in one workflow. A workflow can have up to 50 steps.

When something goes wrong

Every submission creates a run per Form submitted workflow, and every unfinished response that goes quiet one per Form abandoned workflow (shown as Unfinished), listed under Runs with each step’s result. When a workflow fails three runs in a row, the team’s owners and admins get an email, and another when it recovers. How to retry, release, skip or cancel a run is in Runs and fixing failures.