Requesting and Approving
Dual authorisation only works if requests are made clearly and decided promptly. Both halves are habits rather than settings.
Where to find it
Architect Panel → Security:
- Dual Authorisation — the configured actions and their approving groups
Architect Panel → Activity:
- Activity Log — the resulting change, once approved and applied
Requesting
Attempt the action as you normally would. Instead of taking effect it is held, and the approving group is asked to decide.
Give the approver what they need. If the mechanism lets you add context, use it — an approver who has to work out what they are looking at will either delay or approve without understanding, and neither is what the control is for.
Approving
Read the payload, not the summary. The whole value of the control is a second person looking at what will actually change, and a request approved on its title is a request nobody checked.
Verify independently where that makes sense. For a bank detail change, contact the supplier on a number you already hold — not one supplied with the request. Fraud of this kind is convincing precisely because the request looks correct.
You cannot approve your own
The requester is excluded, which is the whole point. If you find yourself needing to approve your own request, the answer is another approver rather than a way around it — and if that happens often, the approving group is too small.
Write the decision note
On approvals as well as rejections. "Confirmed by telephone with the finance contact on the number held" is what makes the approval meaningful six months later. "Approved" is a click.
The note is also what protects the approver. A recorded verification is evidence they did the checking; an empty note leaves them relying on memory.
Rejecting
Say why. A rejection with no explanation is a request that will simply be made again, and the second attempt usually goes to a different approver.
Keep the queue moving
Requests expire, and an expired request means the work did not happen — often without the requester noticing until somebody chases. Decide daily on anything with an operational deadline.
If requests routinely expire, either the approving group is too small or the action should not be under dual authorisation at all.
Do not build a workaround
Where the control is genuinely obstructing legitimate work, change the configuration — remove the action, or widen the group. What must not happen is a second route to the same change that bypasses approval, because that leaves the control in place on paper and absent in practice.
Worked example
A team finds bulk deletions are being held for approval several times a day during a data cleanup, and requests are expiring overnight. Rather than routing around it, they temporarily widen the approving group for the duration of the project and narrow it again afterwards — so the control stays real and the work gets done.
Recommendations
- Read the payload, never just the title.
- Verify independently for anything involving money or identity.
- Write a note on every decision.
- Fix the configuration rather than working around it.