Foundations

Approval delegations

Delegate approval authority while you're out — and now, scope the delegation to specific modules so your document approvals route to your delegate while MOCs wait for you.

For
Quality Managers, approvers planning leave, admins managing org-wide delegations
Find it at
Admin → Approval Routing → Delegations · Profile → Delegations
Reading time
5 min

In one sentence

A delegation says "while I'm out, route my approvals to this colleague" — and now you can pick which approval types the delegation covers, so high-stakes ones (MOC, Exemption) can wait for you while routine ones (Documents) keep flowing.

Three things to remember
  • Default behavior is unchanged. A delegation with no module scope set covers everything — Documents, MOC, Exemption, JHA, and FMEA — exactly like delegations have always worked. Your existing delegations didn't have to be migrated.
  • The "Applies to" field narrows the scope. Pick one or more of on the delegation and only those approvals route to your delegate. Anything else waits for you.
  • Delegations have a date range. Start date and end date — the delegation is only active between those two dates. Outside that range, approvals route to the original person regardless of the delegation row.

A concrete scenario

Anna, the Quality Manager, is out from 12 May to 19 May. She wants:

  • Document approvals to keep moving — the team can't wait a week to publish minor revisions, and her colleague Mei is qualified to sign off.
  • MOC approvals to wait for her — she's the only person in the org with the authority to approve change records, and Mei isn't going to fake-approve them on her behalf.

Two ways Anna can set that up:

  1. One delegation, scoped. Create a delegation 12–19 May, delegate = Mei, Applies to: Document. Documents route to Mei in that window; MOCs queue for Anna and she approves them when she returns.
  2. Two delegations, different applies-to. Create one for Document → Mei, another for FMEA → John (different delegate per module).

The "Applies to" field accepts any subset of . Leave it blank to cover all five.

Where the field lives

Two entry points:

  • Profile → Delegations — delegate your own approvals. Set the date range, pick a delegate, optionally narrow Applies to.
  • Admin → Approval Routing → Delegations — admins manage delegations for anyone in the org. Same form, plus a Delegator field.

Setting up a delegation

  1. Click New delegation.
  2. (Admin only) Pick the Delegator — whose approvals you're delegating away.
  3. Pick the Delegate — who receives the approval tasks.
  4. Set Start date and End date.
  5. (Optional) Pick Applies to — one or more module types. Leave blank for all approvals.

Save. Approvals routed to the delegator during that window now route to the delegate, filtered by the Applies to scope.

What "Applies to" actually controls

Two things, kept consistent:

  • Visibility — the delegate can see the delegator's pending records of the matching modules in their queues, but not the unscoped modules. Documents-scoped delegate sees the delegator's pending document approvals; an MOC submitted to the delegator stays invisible to that delegate until the delegator returns.
  • Approval rights — the delegate can act on the matching modules. Other modules either wait for the delegator or, if there's a fully-unscoped delegation in force as well, route through that one instead.

What it doesn't cover

  • Audits — audits don't use the delegation system. Lead-auditor swaps are handled inside the audit module itself, not here.
  • Routing rules themselves — delegating an approval doesn't update the org's approval-routing rules. The chain still resolves from the rules in Approval routing; the delegate is just the effective signer for the in-flight tasks while the delegation is active.
Watch out for: overlapping delegations

Two active delegations from the same delegator with overlapping module scopes both apply — meaning the most recent one created tends to be the one that picks up new tasks, but historical tasks keep their original delegate. Best practice is one delegation per delegator at a time and let the date range manage transitions.

Compliance angle

Every delegation row is stored in the database with the dates, delegator, delegate, and Applies-to scope. Create / edit / delete events are captured in the row's history, so an auditor asking "who held approval authority on the 14th of May?" can be answered from the data — including which modules the delegation covered.

For high-sensitivity rooms (MOC and Exemption), the safe pattern is to leave the delegation scoped narrowly to documents only, and let the high-stakes approvals queue for the original signer. The Applies to field is what makes that pattern straightforward.

If your organization has Require passkey for approvals turned on, the delegate clicks approve, so the delegate is the one prompted for a passkey confirmation — not the original delegator. Make sure delegates have a passkey enrolled before the policy goes live; otherwise approvals delegated to them will be blocked. See Auth policy.

Permissions

  • Profile → Delegations — anyone with at least one approval-eligible role can create their own.
  • Admin → Approval Routing → Delegations — admin role only. Required to create, edit, or delete delegations on behalf of other people.
← Previous
Approval routing
Next →
Actions
Was this helpful?
Suggest an edit →