Flow steps are the basic building blocks of approval workflows. They define who needs to approve a submission and how approvals are collected. If you want the usual office-then-manager pattern, start with Building a Two-Step Approval.
Flow Types
One (one)
Single-person approval where only one member from the assigned group needs to approve.
Behavior:
- Creates a notification for whichever group member is selected on the form
- Submission advances when that single person approves
Use Case: When you need approval from a specific person chosen by the submitter (e.g., "select your manager to approve this expense").
Multiple (multiple)
Multiple specific people from a group must approve.
Behavior:
- Creates notifications for designated members
- Can be configured to require unanimous approval or just a subset
Use Case: When specific individuals need to review (e.g., "both the department head and finance lead must approve").
All (all)
Every member of the assigned group must approve.
Behavior:
- Creates notifications for all members of the group
- Submission only advances when every member has approved
Use Case: When consensus from an entire team is required (e.g., "all board members must approve this resolution").
Group Select (group_select)
Routes the submission to a group chosen while the form is in flight.
Behavior:
- Presents a selection of pre-configured groups
- The choice is made by whoever is acting on the step before this one; when a group select step comes first, the submitter chooses as part of submitting
- The selected group then receives the submission for approval
- Can optionally auto-share the submission with the selected group
Use Case: When submissions can be routed to different departments based on a human decision (e.g., "select your regional office for processing").
Wait for Submissions (wait)
Holds the submission until every submission created from it has finished.
Behavior:
- Parks the submission: nothing is pending on anyone, and no notification goes out
- Watches the submissions spawned from this one - by a Create Submission trigger or shared connected forms - and moves on only when all of them reach a final status
- If any spawned submission is denied, the waiting submission is denied with it
- Carries no group and no attached form of its own
Use Case: A registration that spawns a waiver per participant should not reach final approval until every waiver is in.
Two other step types make decisions rather than collect approvals: Conditional steps branch the workflow, and Dynamic steps pick approvers from the submission's own data. Collective steps hold the submission while someone completes a set of forms.
Configuration Options
| Option | Description |
|---|---|
| Name | Optional custom display name for the step |
| Group | The group the step draws its approvers from. Not used by group_select, dynamic, or wait steps |
| Unanimous | Every assigned member must approve before advancing. Participants can be added or removed mid-step by an admin or form manager, and a unanimous step left with no participants completes on its own |
| Isolate responses | On unanimous steps with an attached form, each participant sees only their own response |
| Prevent self-selection | On one and multiple steps, keeps the submitter from picking themselves as approver |
| SMS | Also notify this step's approvers by text message |
| Muted | Don't send notifications for this step (manual follow-up) |
| Can edit form | Allow editing the submission during this step |
| Escalatable | Adds a Reassign action so an approver can escalate the submission to someone outside the flow, by name and email |
| Auto-share group | Automatically share the submission with another group when this step completes |
| Action buttons | Each step's Approve, Request Info, Send Back, and Deny buttons can be renamed or turned off individually |
| See all submissions | all steps normally let the group see every submission on the form; this can be switched off per step |
Any step except Wait for Submissions can also carry Deadlines - escalations that fire when a submission sits on the step too long.
Step Sequencing
Flow steps are ordered, and a submission moves through them top to bottom: when a step completes, the submission advances to the next step in sequence, or to final approval after the last one. Any step type can follow any other; the order you arrange them in the flow editor is the order they run.