Loading

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.