Approvals workbench
The request-centric decide surface and approval-pipeline governance view — where approvers act with full context and admins oversee what is in flight.
The approvals workbench gives an approver one place to decide an access request (or a role, policy, or exception approval) with the full context an item-level inbox card cannot show, and 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 request- and subject-centric companion to the review inbox, which stays the personal, cross-domain, item-level triage spine.
What it is (and is not)
The approvals workbench is a presentation and governance surface. It does not re-own the approval-chain decide mechanics — those live in the review inbox. Instead it provides two things neither the item-level inbox nor the requester's "My requests" view offers:
- A request-centric full-context decide surface — the whole request bundle in one place.
- Pipeline governance — an oversight view of every approval in flight.
Access reviews (recertification) stay in their own workbench — see Access reviews. The approvals workbench covers approval kinds only: access requests, and role, policy, and exception approvals. Two clean decide-workbenches, no overlap.
The unified decision inbox vs. full context
Both the review inbox and the approvals workbench can decide an item — they share the same decide endpoint and the same canonical approval-chain flow. They differ in intent:
- The review inbox is the personal, item-level triage spine: "I have N things waiting on me," fast single-item decisions.
- The approvals workbench is the subject-centric, full-context surface. An inbox card carries an "open full context" link into the workbench when the approver needs the whole picture before deciding.
They divide the work; they do not duplicate the mechanics.
Deciding with full context
When an approver opens an access request, the workbench 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 |
| Surface | This workbench + the review inbox | The access-reviews workbench + the review inbox |
Keeping them separate means two focused decide-workbenches instead of one overloaded queue.