Approval types and patterns

What it does

The approval type you pick on the action decides how many people have to respond and what they're allowed to say. Everything more complicated than that — chains, escalation, conditional routing — you build yourself out of multiple approval actions and flow logic.

Key facts

Five types ship in the box: Approve/Reject Everyone must approve, Approve/Reject First to respond, Custom Responses Wait for all responses, Custom Responses Wait for one response, and Sequential approval.
With "Everyone must approve", a single rejection completes the request immediately — the remaining approvers never get to respond.
Custom responses let you replace Approve and Reject with your own option list, which is how you handle tiered outcomes such as discount bands.
Sequential approval requests one approver at a time in a defined order, and each has to respond before the next is asked.
Read the result from the Outcome output. For basic and await-all types the valid responses are literally "Approve" and "Reject", and they're case-sensitive.
Multiple approvers go in the Assigned to field separated by semicolons.
Parallel approvals across different groups mean separate approval actions in parallel branches, then logic to combine the outcomes. There's no built-in quorum or "any two of five".
Markdown is supported in the Details field, which is the only real formatting control you get over what the approver sees.

When to use / skip

First-to-respond suits any approval assigned to a role rather than a person — a duty manager, a team rota, anyone-in-finance. Everyone-must-approve suits genuine multi-party sign-off where each party is accountable separately. Use custom responses the moment the business asks for a third option, because encoding "approve but with conditions" into a rejection plus a comment is a decision you'll regret. Skip sequential chains longer than about three steps; each hop is another place the process stalls, and the business rarely needs the sequence as strictly as it says it does.

Configuration decisions

Whether approvers are named individuals, a group, or resolved at runtime from data such as a manager lookup.
First-to-respond versus everyone-must-approve, and whether the business genuinely understands that one rejection ends an await-all request.
Whether default Approve/Reject is enough or the process needs custom responses.
Sequential chain versus parallel branches versus a single approval with several assignees.
Where escalation kicks in, since you build that yourself with a parallel branch, a delay and a second approval.

Gotchas

Outcome comparisons are case-sensitive. equals 'approve' silently fails and the flow takes the wrong branch.
Custom responses plus everyone-must-approve plus a long assignee list can fail on results field size. Keep that combination small.
Sequential approval is one action, but it doesn't give you per-step timeouts or per-step escalation. If you need those, build the chain out of separate actions.
A manager lookup that returns nobody produces an approval assigned to nothing, which fails at run rather than at design time. Validate the assignee before the approval action.
There's no quorum type. Every "two of these four people" requirement turns into custom logic, so price it accordingly.

Consultant notes

Ask the business what happens when the approver says neither yes nor no. That question surfaces the custom-response requirement, the escalation requirement and the timeout requirement in one go.
Resolve approvers from data rather than hardcoding names. Hardcoded approvers are the top cause of broken approval flows six months after go-live.
Long sequential chains are usually the current paper process transcribed rather than a real control. It's worth challenging once, politely, with the cycle time attached.
Get the outcome branch logic reviewed. Case-sensitivity and null outcomes account for a surprising share of approval defects.

Worth revisiting if new approval types appear or the results field size limit changes