Workflow Approval Steps: Build Human Gates Fast
Fully automated workflows are the goal — until something goes wrong at scale and you wish a human had checked it first. Workflow approval steps let you keep automation speed while inserting a deliberate pause for review, sign-off, or escalation. This guide shows you exactly where to place those gates, how to wire them up in CraftMyFlow, and how to avoid the two mistakes that turn approval steps into bottlenecks.
Why approval steps break more often than they should
Most builders add an approval step as an afterthought — a single notification sent to a Slack channel with a thumbs-up emoji as the "process." That works for a week. Then the approver goes on leave, nobody has a fallback, and the workflow either stalls indefinitely or someone bypasses the gate entirely.
The real problem is treating approval as a notification rather than a state. A notification tells someone something happened. An approval step changes the workflow's state — it holds execution, waits for a structured response, and routes to different branches depending on the outcome.
Getting that distinction right is the entire job.
The four approval patterns and when to use each
Not every approval looks the same. Matching the pattern to the use case saves you from over-engineering a simple sign-off or under-engineering a high-stakes one.
| Pattern | How it works | Best for |
|---|---|---|
| Single approver, synchronous | Workflow pauses; one person responds via email or form; execution resumes | Budget requests, content sign-off |
| Sequential chain | Approver A must approve before the request reaches Approver B | Contracts, compliance reviews |
| Parallel approval | Multiple approvers notified simultaneously; all must respond | Policy changes needing cross-team consensus |
| Majority vote | Request goes to a group; a set threshold (e.g.undefinedof 3) unlocks the next step | Committee decisions, editorial boards |
Start with single approver unless the process already requires more. Adding complexity you don't need creates more failure points than it prevents.
How to build a single-approver gate in CraftMyFlow
This worked example uses a content publishing workflow: a writer submits a draft, an editor approves or rejects it, and the workflow publishes or routes back for revision.
Stepundefined— Trigger the workflow on form submission Use a form trigger (or a webhook from your CMS) that fires when a draft is marked "Ready for review." Capture the draft URL, the writer's name, and the submission timestamp as variables.
Stepundefined— Create an approval request record Before notifying anyone, write the request to a data store (a connected Airtable base or a CraftMyFlow-native store). Give it a status field set to pending. This is your state. Everything downstream reads from it.
Stepundefined— Notify the approver with an actionable link Send the editor an email or Slack message that includes two links: one that sets the record's status to approved, one that sets it to rejected. These links hit a CraftMyFlow webhook step — no separate app required. Browse the available trigger types on the /browse page if you want alternatives like a dedicated approval form.
Stepundefined— Add a wait step with a timeout This is the step most builders skip. Set a wait step that listens for the status field to change. Add a timeout —undefinedhours is a reasonable default for content review. If the timeout fires without a response, route to an escalation branch (notify a backup approver or flag the item as overdue). Without a timeout, stalled approvals are invisible.
Stepundefined— Branch on the outcome After the wait resolves, read the status field and branch:
approved→ publish the draft, notify the writer, archive the requestrejected→ send the writer the editor's comments, reset the draft status toin revisiontimed out→ notify the team lead, leave the record inpendingfor manual resolution
Stepundefined— Audit the decision Write the approver's name, their decision, and a timestamp back to the record. This costs one extra step and pays back immediately the first time someone asks "who approved that?"
Where to put approval steps in an existing workflow
If you have a workflow already running and need to retrofit an approval gate, use the /analyze view to see where your workflow's execution time clusters. Long-running steps or high error-rate steps are usually the right candidates for a human review gate — not because humans fix errors, but because those are the points where bad data or bad decisions compound.
A gate placed after a high-risk transformation step catches problems before they propagate to five downstream apps.
The timeout and escalation checklist
Before you publish any workflow with an approval step, confirm each item:
- [ ] A timeout duration is set on every wait step (not "wait forever")
- [ ] A fallback approver is defined for when the primary approver doesn't respond
- [ ] The approval link is unique per request (not a static URL that could be replayed)
- [ ] The decision is written to a data store, not just inferred from the notification response
- [ ] Rejected requests route somewhere — not to a dead end
- [ ] You have tested the timeout branch, not just the happy path
The last item is the one most builders skip. Run the workflow, wait for the timeout to fire, and confirm the escalation branch actually works before you go live.
Connecting approvals to tools your team already uses
Approval steps work best when the approver doesn't have to learn a new tool. If your team lives in Slack, the approval action should come from Slack. If they work in email, the link in the email is the interface.
For teams that need richer approval forms — showing the full context of what's being approved, not just a yes/no — a lightweight form tool works well as the approval surface. If you're evaluating which form or document tool fits your stack, Papersnap handles structured document capture that can feed cleanly into a CraftMyFlow approval trigger.
For reusable approval workflow structures, the /templates page has starting points you can clone and adapt rather than building from scratch.
Key takeaways
- Approval steps are state changes, not notifications — design them that way from the start
- Every wait step needs a timeout; every timeout needs an escalation branch
- Match the approval pattern (single, sequential, parallel, majority) to the actual process before building
- Write every decision to a data store for auditability
- Test the rejection and timeout branches before going live — the happy path is rarely where things break
- Retrofitting approvals into an existing workflow is easier when you analyze execution data first
If you're ready to wire up your first approval gate, open CraftMyFlow and start from a template at /templates — the approval workflow templates include the wait step and escalation branch pre-configured, so you're not building the timeout logic from scratch.