Dual Authorisation

Dual Authorisation

Some actions should not be one person's decision. Dual authorisation holds the action until a second person approves it.

Where to find it

Architect Panel → Security:

• Dual Authorisation — which actions require approval, and by which group
• Permissions — the groups that do the approving

Architect Panel → Activity:

• Activity Log — the change once it is applied

How it is configured

An entry names the action, the datastore it applies to, the approving group, and whether it is enabled. Anybody in the approving group can approve; the requester cannot approve their own request.

The change is parked, not applied

This is the part worth understanding. When a controlled action is attempted, the intended change is captured as a payload and held in a pending state. Nothing is applied to the record.

That is different from — and much stronger than — applying the change and asking somebody to review it afterwards. A change applied and later reversed still happened: it was live, it may have triggered notifications, integrations or downstream automation, and reversing it is a second event rather than an undo.

What a request records

• The action, record and the payload that will be applied.
• The requester and when they asked.
• The state.
• The approver, the decision time and a decision note.
• An expiry, after which the request lapses.

Requests expire

A pending request does not wait indefinitely. This is deliberate: an approval given three weeks late is given on stale information, and the approver has usually forgotten the context that would let them judge it.

Choose the actions carefully

Dual authorisation adds a person and a delay to every occurrence. Applied to a routine action it becomes a formality — approvers rubber-stamp what they cannot realistically assess, and the control becomes theatre while still costing time.

Reserve it for the genuinely consequential: changing bank details, releasing a payment, deleting records in bulk, altering permissions, disclosing sensitive information. The test is whether an approver would actually be able to say no.

The approving group must be able to respond

A group of one is a single point of failure — nothing gets approved while they are on leave. A group of everybody is not a control. Three or four people who understand the action is usually right.

Worked example

A finance team puts supplier bank detail changes under dual authorisation, approved by a group of three. A clerk updates a supplier's account number; the change is held. The approver telephones the supplier on the number already on file, confirms the request is genuine, and approves with a note recording the call. The one time the request was fraudulent, the change was never applied — because it was never live to begin with.

Recommendations

• Reserve it for actions an approver could genuinely refuse.
• Three or four approvers — not one, not everybody.
• Require a decision note on approvals, not just rejections.
• Review lapsed requests — they usually indicate a process that is not working.

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.