The wait-for-approval step: adding a human decision to your workflows

Thursday, 4:40 p.m. On the sales team of a furniture wholesaler, the quote workflow is doing the same job for the third time that day: quote built, PDF generated, email sent. This one carries a 34 percent discount, because the rep read the price list one row off. The workflow did not object, since nobody had told it to object. The sales manager saw the discount the next morning, after the customer had already replied "we accept". The automation ran flawlessly. The problem was that it never stopped anywhere.

This piece is about where a flow should pause and how that pause should be built. We start with which steps genuinely deserve a human pair of eyes, then work through where the wait-for-approval step actually cuts the run, whether approval should sit with a person or a role, what the approver needs to see on screen, how to set the threshold, what the flow should do when the clock runs out, how the pause looks to the customer, how to rehearse the step before it goes live, which numbers tell you the gate is working, and where an approval gate does more harm than good.

Which steps genuinely deserve a human pair of eyes?

An approval gate is never free. Every gate you add costs a wait, a notification, and a slice of somebody's attention. So the question is not "where should we add approvals" but "which step cannot afford to run unattended". The only test that holds up is reversibility: when this step goes wrong, is the fix a click, or an apology call?

Four questions settle it. Does the step send something outside the company? Does it commit money, a discount, or a credit? Does it permanently delete or close a record? And when it misfires, who notices first, you or the customer? Any step that answers yes twice belongs behind a person.

• Outbound content: quotes, contracts, invoices, and anything broadcast to a list.
• Financial commitments: discounts, refunds, credits, changes to a payment plan.
• Irreversible state changes: closing an account, cancelling a subscription, archiving a record.
• Reputational exposure: any channel where a bad send can be screenshotted and shared.

Asking for approval on anything outside that list hands back the time the automation just saved. We argued the general boundary in where automation should stop and a person should take over; the difference here is that the decision lives inside the flow as a step, not in a policy document.

Where does the wait-for-approval step actually stop the run?

The Wait for Approval step sits on the canvas as a node and suspends everything downstream of it. When the run reaches that node it stops advancing, a notification goes to the person you picked, and if the window expires the flow does not proceed without approval. That last clause reads like a footnote, but it defines the whole behaviour: the default is not "let it through", it is "hold".

What gets suspended is the run, not the workflow. The same flow keeps executing for other quotes at the same time, and each run waits for its own decision. That is why an approval gate should not be pictured as a bottleneck in the pipeline. The queue forms in the approver's attention, not in the automation.

The most common placement mistake is putting approval at the end. It belongs immediately before the risky action: after the step that builds the quote, before the step that sends it. That way the approver reviews the artefact that is actually going out, not an abstract intention. The broader mechanics of building rules on a canvas are covered in automating processes with conditional rules.

Should approval sit with a person or a role?

Typing a single name into the flow is easy, and it works perfectly for about three weeks. In week four that person goes on leave. The most common failure of an approval gate is organisational rather than technical: exactly one person can decide, and that person is not at their desk.

The practical fix is to attach approval to a role and keep at least two people in it. Whoever responds first moves the run forward, and the name of the decision maker is recorded. Single-person approvals only make sense for decisions that genuinely cannot be delegated, and there are fewer of those than you think. We went through how discount authority in particular gets distributed in who signs off on a discounted quote.

The second decision is whether the approver must be someone other than the requester. In a small team that rule creates friction. Once a countable sum is involved, it stops being optional. If an audit conversation is anywhere on the horizon, set the rule at the start; retrofitting separation of duties is always harder than building it in.

What does the approver need to see on screen?

An approval request has to carry everything the decision needs in one view. "Quote #4812 is awaiting your approval" is not a notification, it is homework: the recipient opens the CRM, finds the record, reads the history, and only then decides. Multiply those three minutes by every request and you have the real cost of the gate.

A well-built request carries the subject of the decision, the size of the deviation, a reference to compare it against, and the person who asked. Not "34 percent discount" but "34 percent discount, this account averages 12 percent, the category ceiling is 20, requested by Dana". The only thing the approver should have to weigh is the justification for the gap.

The same logic applies to paperwork-driven flows: if a case can move forward only with a missing document, the approval request should name the document. We walked through that setup in automating document collection from customers.

How do you set the threshold?

The threshold is the single dial between "approve everything" and "approve nothing", and set badly it collapses into one of the two. Too low, and the approval queue fills with routine requests; the approver starts clicking through without reading and the gate becomes ceremonial. Too high, and it never opens at all.

The right starting point is your own history. Sort the last quarter's requests by size and take the value that cuts off the top tenth. That way the gate catches what is genuinely unusual rather than what is merely typical. The table below shows how a distribution like that turns into decision criteria; the values are illustrative, so replace them with your own.

Step type	Example threshold	Approver	On timeout
Standard quote	At or above list price	None	—
Discounted quote	Up to the category ceiling	Team lead	Escalate after 4 hours
Above-ceiling discount	Any rate past the ceiling	Sales manager	Stays on hold
Refund	Any amount	Finance plus manager	Stays on hold
Broadcast message	Above a set recipient count	Marketing owner	Cancel after 24 hours

A threshold is not a set-and-forget setting. Three months in, look at what share of requests lands in the approval queue: if the percentage is climbing, either the business changed or the threshold went stale. We covered the shape of approval processes end to end in approval workflow automation.

What should happen when the clock runs out?

Every gate has a timeout behaviour; if you do not define one, the default applies and the flow does not proceed without approval. That is the safe side, but it is not the only option. Three behaviours are defensible: hold, escalate, or quietly end the run.

The choice follows the nature of the step. For financial commitments, holding is right — if nobody answered, the discount should not be granted either. For time-sensitive but low-risk steps, such as sending a reminder, escalating makes more sense: the decision moves to someone else and the flow keeps going. We laid out how to chain those handoffs in routing to the right person before the SLA is breached.

The third behaviour, ending quietly, only suits repeatable steps. A campaign message that did not go out this cycle goes out next cycle. But if a refund request closes quietly, nobody finds out until the customer calls. The rule is simple: silent expiry is only for steps that never created an expectation on the customer's side.

How does a waiting run look to the customer?

The most expensive side effect of an approval gate is the silence it creates. The person waiting on the quote knows nothing about your internal review; all they know is that they asked for something two hours ago and heard nothing back. That is why an approval step almost always needs an interim message beside it.

The interim message should be short and honest: the request arrived, it is being prepared, and here is when you will come back. Naming a window is a risk, but staying vague is a bigger one; commit to a generous limit and beat it. Channel matters too, because on instant channels the expectation is measured in minutes, and what the automatic reply says shapes how long people are willing to wait, as we covered in setting up WhatsApp auto-replies.

Put the notification step before the approval step, not after. Placed after, it is delayed by exactly the thing it was meant to explain, so it goes quiet precisely when it is needed most.

How do you rehearse the step before it goes live?

Approval gates fail quietly when they are wired wrong. The wrong role is selected, the notification reaches nobody, the run waits, and nobody knows it is waiting. Discovering that in production is expensive.

The Dry Run Test closes that gap: it walks the flow through with sample data, shows step by step which nodes would fire, and sends no real messages. You see which condition triggers the approval, which branch is taken, and whose queue the notification lands in, all before publishing. Test two scenarios separately: a request below the threshold should never touch the gate, and one above it should stop there.

The second safety net is Version History. Every save is stored as a version, so if the day you change a threshold brings behaviour you did not expect, you roll the flow back with a single click, and the state before the rollback is kept too. That makes experimenting cheap. The same discipline applies to the rest of the automated steps around the gate; the setup logic in lifting repetitive sales work with no-code triggers carries over directly.

Which numbers tell you the gate is working?

Three numbers measure the health of an approval gate: how many requests are pending, how long a decision takes on average, and what share gets rejected. Read together, they tell you whether the gate is doing anything at all.

If the rejection rate approaches zero, the gate is not working; the approver has turned into a rubber stamp and the threshold is too low. If average decision time is stretching, the problem is capacity rather than threshold: either widen the approving role or move low-risk branches outside the gate entirely. And if the pending count swings through the day, the cause is usually working hours rather than volume.

Analytics and logs show how long each step took and where runs got stuck; the approval step is usually the longest line in that list, and that is fine. What is not fine is that line growing week over week. Automatic Diagnostics catches the quiet failures — a disconnected step, a flow that has never fired, a channel that was never linked — and when approval notifications reach nobody, the cause is usually sitting right there. We took up the wider question of how much room to give automation in when to trust automation on the advertising side.

Where does an approval gate do more harm than good?

The worst use of an approval gate is patching a trust problem with process. Routing every task from one team member through review is not a control mechanism, it is a delay generator: it slows the work and pulls the approver's attention away from the decisions that actually carry risk.

The second misuse is gating regular, predictable sends. Approving every step of a time-spread sequence makes the sequence unusable; the approval belongs on publishing the sequence, not on each message inside it. Content approved once can be sent thousands of times, a distinction we drew through trigger design in scaled personalisation with triggered flows.

The third is turning approval into a signature-collection ritual. Passing the same request through three people in sequence does not divide the risk by three; it spreads accountability until nobody really looks. One accountable approver, handed a well-prepared case, outperforms a chain every time.

If you want to try putting a gate in front of the risky step in your own flow, create a Rocketly account and define your first one in a few minutes.

FAQ

How long can a run sit waiting for approval?

You set the window, and it should track the nature of the step. A few hours is plenty for a financial commitment, while flows waiting on documents reasonably run for days. When the window expires the flow does not proceed without approval, so waiting is the safe default rather than a failure state.

What happens if the approver is away?

Attach approval to a role instead of a single name and the problem disappears: anyone in that role can decide, and the name of whoever did is recorded. For genuinely single-person approvals, setting the timeout behaviour to escalate keeps the run from waiting indefinitely.

Does an approval step block the other branches of the flow?

No. What pauses is the individual run, not the workflow definition. The same flow keeps executing for other records, and each run waits on its own decision. If you use Conditional Branching to route below-threshold requests around the gate, most runs never touch it.

Can approval decisions be audited later?

Yes. Because every run is recorded, you can trace which request was approved by whom and when, or which ones were left on hold. Changes to the flow itself are stored as versions, so the question "which rules were in force when this was decided" also has an answer.