In one sentence
Admin → Approval Routing is the single page where you configure who approves what across five modules — Documents on its own tab, MOC and Exemption sharing a routing-rule shape, and JHA and FMEA sharing a defaults shape — so each record's chain is decided by the rules you set, not by whoever creates it.
- One page, six tabs. Documents · MOC · Exemption · JHA · FMEA · Delegations. Each module's tab configures the chain that fits how that module is actually used.
- When the chain applies depends on the module. Document rules auto-apply on save — the moment a new document is created, its reviewer and approver fields are pre-filled from the matching rule. MOC, Exemption, JHA, and FMEA rules feed in at submission time — the chain is resolved when the record moves out of draft.
- The most specific match wins. All tabs follow the same precedence rule: a rule with every dimension set beats a rule with one or two dimensions blank. Falls all the way back to a catch-all if you've set one.
Documents tab
Document routing is configured along three dimensions:
| Dimension | What it captures |
|---|---|
| Facility | Single facility, or All facilities for an org-wide default |
| Document class | The class taxonomy from your document admin (Policy, Procedure, Work Instruction, etc.) |
| Category | The category the document is filed under |
For each combination, you pick a Reviewer and an Approver. When a new document is created or its facility/class/category changes, the system looks up the most specific matching rule and pre-fills both fields. Authors can override the suggestion if your org policy allows it; routing rules can also be marked enforced, locking the fields so authors can't override.
Approval flows through three serial steps: submitter prepares, reviewer comments and forwards, approver finalises. The reviewer step is optional in the chain — a rule can leave Reviewer blank for a one-step Approver-only flow. Every rule change writes a row to the change log so the audit trail is complete.
MOC and Exemption tabs
MOC and Exemption share a routing-rule shape: pick a Change Type and a Risk Level, and the rule sets a 3-step approver chain (Step 1 required, Step 2 and Step 3 optional).
| Module | Dimensions |
|---|---|
| MOC | Change Type (your configured types) × Risk Level |
| Exemption | Risk Level only — Exemptions don't have a configurable Change Type, so the column is hidden on this tab |
Each step picks a member from the org. When the record is submitted for approval (not when it's created in draft), the system resolves the chain from the matching rule and writes the resolved approvers onto the record. From that point the chain is the chain — you can't change rules under an in-flight approval and have them take effect retroactively.
The Step 1 approver is required on every rule. Steps 2 and 3 are blank-allowed, so a low-risk MOC can route through one signer while a high-risk one routes through three.
JHA and FMEA tabs
JHA and FMEA share an entity-defaults shape — a different model from MOC/Exemption because these modules don't have a clean enum for "type". Instead, admins configure defaults per subtype + facility:
| Field | Notes |
|---|---|
| Subtype | Free text — process, design, equipment, whatever your team writes. Existing rows surface as autocomplete suggestions, so consistent typing keeps the table tidy. Blank means "all subtypes". |
| Facility | Single facility, or All facilities for an org-wide default |
Each combination configures a step chain (the same 3-step shape underneath, with Step 1 required and the others optional). At submission time, the system picks the matching default and resolves the chain in the same way it does for MOC and Exemption.
JHA/FMEA subtypes are free text by design — but typos can split a single workflow across two near-identical rules ("process" and "Process" don't match). Use the autocomplete; if you spot a duplicate, edit one rule's subtype to match the other and the orphaned default disappears.
When rules don't match
If no rule matches a record:
- Documents — the reviewer/approver fields stay blank, the author picks them manually before submitting.
- MOC, Exemption, JHA, FMEA — submission is blocked with an error pointing the user at this admin page. Configure a rule, retry submission.
Set an org-wide catch-all (Facility = All facilities, Subtype = blank, etc.) on each tab if you want the system to never block submission.
Delegations tab
A separate tab on the same page covers delegations — when an approver is unavailable, who picks up their tasks. See Approval delegations for how that works, including the new per-module Applies to scoping.
Change log on every tab
Every tab — MOC, Exemption, JHA, FMEA, and Delegations — carries a collapsed Change log section at the bottom. Expand it to see the chronological feed of every create, edit, and delete on that tab's rules, with the actor, timestamp, and a field-by-field before/after diff for updates.
The feed is driven by the same row-change capture trigger that powers per-record history, so the trail is database-level and append-only — admins can't quietly rewrite who configured what.
The Documents tab keeps its own bespoke change log. Document routing has richer diff semantics (the facility / class / category scope tuple makes a generic diff hard to read), and the auto-apply behavior — saving a rule pushes the new approvers to every existing matching doc — is worth surfacing in a dedicated view. Both surfaces give an inspector the same kind of evidence: when a rule changed, who changed it, and what it looked like before.
Permissions
Configuring approval routing requires the Manage routing rules permission. The default Admin role has it; Standard User doesn't. If you've built a custom role that owns approval-flow configuration (often the same person who manages process owners), grant Manage routing rules on that role and you don't need to give them full admin.
Heads up if you maintain custom roles: until recently, Manage routing rules existed in the permission catalog but wasn't actually wired to anything — granting it didn't open this page. That's been fixed; the permission now meaningfully gates the entire approval-routing admin page. If you previously gated this access via Access audit admin, switch your custom roles to Manage routing rules instead.
Routing decides who approves; step-up decides how they prove it. If your organization has Require passkey for approvals turned on, every approver resolved by these rules is prompted for a fresh passkey confirmation when they click approve — make sure approvers (and their delegates) have a passkey enrolled before the policy goes live. See Auth policy.