Dual-control approval workflows

A dual-control workflow decides who has to approve an access request before it activates, and how many of them. Configure one from Privileged → Safes, in the Dual-control workflows section below the safe table.

Binding a workflow

A workflow binds either to one specific safe or acts as the Organisation default, applying to any safe with no workflow configured of its own. When a request is raised, the platform resolves the governing workflow for that credential's safe in this order: the safe-bound workflow if an administrator configured one, otherwise the organisation default, otherwise a conservative built-in fallback (one approver, 24 hours) so an organisation that never configured a workflow at all is not permanently broken.

A workflow has a name, an optional description, a minimum approver count, an optional step timeout (how long one approval step waits before escalating — leave it empty for no per-step limit) and an optional overall timeout (how long the whole request stays open across every step).

Deleting a workflow

The workflow table's Actions column has a Delete action, with a confirmation step before anything happens. Deleting a workflow is permanent — there is no undo, and no route to restore it afterwards.

If you need to remove a workflow that is currently active on a safe, deactivate it or rebind the safe to a different workflow first, then delete it.

Who can approve — and who genuinely cannot

An approver is resolved through real IAM group and role membership against the authorize_requests safe permission — not a separate, parallel role vocabulary. Two rules are enforced regardless of what a workflow's own configuration says:

• The person who raised a request can never approve it themselves.
• An approver who raised a different request against the same workflow also cannot approve that one — separation of duties applies to approvers as a group, not just to the specific requester of a given request. Two independent, distinct approvers are required even when the same person happens to hold both requester and approver permissions on a safe.

Break-glass access follows a separate, older approval model with two fixed roles of its own and is not affected by anything in this article — see Break-glass access.

What survives a restart

Every workflow step is persisted as it is submitted, approved or rejected, so an approval's history is recorded. What is not recovered from that record is an in-flight approval's live progress after a process restart — the engine tracking who has approved so far is in-memory. This is defence-in-depth only: every check that actually matters for security (self-approval refusal, the safe permission check, the distinct-approver-count requirement) is re-verified from scratch on every approval call and never depends on remembered in-memory state, so this gap cannot be used to approve something that should have been refused. It can, in a genuine restart mid-approval, mean a request needs its approvals re-submitted rather than resuming exactly where it left off.

What to read next

1. Access requests and approvals — the requester's side of this flow.
2. Ticket validation for access requests — an optional, separate control that can also gate a request.
3. Safes and safe members — the authorize_requests permission this whole mechanism depends on.