Approvals workbench
The approval-pipeline oversight view — what is in flight, where it is stuck, and who is holding it up.
The approvals workbench gives a governance administrator or auditor a dedicated view of the approval pipeline: what is in flight, where it is stuck, and what is breaching a service-level agreement (SLA). It is the subject-centric companion to the review inbox, which is where approvers actually decide.
Deciding happens in one place
Approvers decide in the review inbox. Not here, and not in two places.
This is worth stating plainly because the product used to do it both ways, and that was a mistake we corrected rather than a design we defend. When a decision can be taken on two surfaces, both have to carry the full context an approver needs — or one of them quietly becomes the surface where people decide with less than they should. The fix was not to make the two agree; it was to stop having two. The full-context request bundle moved into the inbox, and this workbench kept everything that is genuinely oversight: seeing the pipeline, and reassigning a step that is stuck on the wrong person. A deep link that used to open a decision here now lands on the inbox.
So the split is by question, not by permission:
- The review inbox answers "what is waiting on me?" — and is where you answer it, with the whole request bundle in front of you.
- The approvals workbench answers "what is the state of everything in flight?" — pipeline health, ageing, SLA breaches, and the one administrative action that moves a stuck item along: reassignment.
Access reviews (recertification) have their own workbench with the same posture — oversight there, deciding in the inbox. See Access reviews. This workbench covers approval kinds only: access requests, and role, policy and exception approvals.
What an approver sees when deciding
Deciding happens in the inbox, but what the approver is shown is worth describing here, because it is what makes a single decide surface sufficient. Opening an access request shows the whole request bundle, not truncated identifiers:
- Every requested item with a human-readable label and per-item trust context.
- The on-behalf-of target, when the request was made for someone else.
- The separation-of-duties (SoD) preflight — which conflicts approving this would create.
- The existing-access delta — what the request adds over the identity's current access, including access held transitively.
- The requester's risk and peer context.
- The complete multi-step approval chain, with the approver's own step highlighted, who is before and after them, the quorum, and any fan-out — all resolved to real people, not roles.
The approver then approves or rejects with a note, once, in context. Owner-kind steps (resource owner, application owner, system owner, context owner) are resolved through the ownership cascade, so the "who's left" view names actual people.
Multi-step approver chains and quorum
An approval subject moves through an approver chain of one or more steps. Each step has a quorum: all approvers must approve, any one may, or a specified number of a set (n-of-m). A step can fan out — one logical step producing several parallel tasks that share a fan-out group and are evaluated together against the step's quorum. The chain advances to the next step lazily, once the current step's quorum is met, and provisions once the whole chain completes.
The chain structure itself is configured in governance settings (approval chains), not authored in this workbench — the workbench consumes it. See Approver chains for how chains are built and resolved.
Per-item resolution — each item resolves its own chain
A request can be a cart of several items. Approval is resolved per requested item: each item resolves its own approver chain based on what that item is and who owns it. Where two items would resolve to an identical chain, those chains are deduplicated so the same approver is not asked twice for the same effective decision. This is why the subject-centric row is bundle-aware: the human wants to see the whole cart and decide per item beneath it, rather than approve N separate near-identical requests.
Bulk decisions preserve this integrity. An approver can multi-select and bulk approve or reject, but each underlying call keeps its own quorum, its own self-approval guard, and its own SoD check — there is no blanket approve.
Self-approval handling
When a step's resolved approver turns out to be the requester, that step is marked as auto-approved because you were the requester — surfaced honestly, never a silent green tick. This is the same separation-of-duties rule as in access reviews: a person cannot approve their own access through the chain. Where the self-review guard applies to a step the person is genuinely asked to decide, the decide action is refused server-side and the step must be reassigned first.
Governing the pipeline
An administrator or auditor opens the oversight view to see every approval in flight. This view is global by design (all in-flight and decided approvals) and server-side paginated so it holds at realistic volumes.
Typical governance actions:
- Filter by approval type, status, SLA (overdue or due-soon, from each task's due date), requester, or risk.
- Reassign a stuck step — for example, a chain waiting on a terminated approver's step — to another approver.
- Review decided history and export it as a comma-separated-values (CSV) file for an audit engagement.
An auditor sees the same oversight, read-only. A requester does not act here at all — their own request tracking and the ability to withdraw stay on the "My requests" view.
💡 Tip
SLA in the first version is surface plus manual: overdue and due-soon cues plus manual reassign. There is no automatic escalation policy yet — a stuck chain is made visible so a human can act on it.
How it differs from access reviews
Both surfaces route human decisions through the same decision engine, but they answer different business questions:
| Approvals workbench | Access reviews | |
|---|---|---|
| Question | "Should this request be approved now?" | "Is this existing access still correct?" |
| Trigger | A person (or policy) requesting access | A rolling clock, an event, or a campaign |
| Subjects | Access requests, role, policy, exception approvals | Assignments, roles, policies, identity validity, ownership, accounts |
| Oversight | This workbench | The access-reviews workbench |
| Deciding | The review inbox | The review inbox |
Keeping the two questions separate means two focused oversight surfaces rather than one overloaded queue — while the person doing the deciding still has a single place to go.