Approval gates

A gate holds an action until a named person approves it. The work is already done; the decision is not.

Adding one

On any workflow step, set Requires approval and choose who approves:

• The case owner. Fast, and appropriate for routine correspondence.
• A named role. Any Supervisor in the owning team.
• A specific person. Use sparingly — it stops when they are on leave.
• A second person. Anyone except whoever prepared the action, for genuine four-eyes.

Where approval happens

Gated actions appear on the approver's queue and on the case timeline. Approving from the timeline shows the full context, which is the point.

The approver sees exactly what will happen: the correspondence as it will send, the stage it will move to, the document it will file.

Timeouts

A gate can escalate after a set period — to a Supervisor, or to the whole team. Without a timeout a gate waits indefinitely, and a case waiting on an approver who left in March is a failure mode worth designing out.

Four-eyes

A second person prevents self-approval, including when the preparer is a Supervisor with permission to approve their own team's work. This is the setting to use where a policy requires separation of duties; it is enforced rather than expected.

Gates and autonomy

A gate is a property of the workflow step. An autonomy level is a property of the worker's action. Where both apply, the gate wins — an action set to Act still waits if the step that triggers it is gated.

That ordering is deliberate: it means a workflow author can guarantee a human decision without needing to know how autonomy is configured.