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. The SoD preflight names each conflicting rule and its reason, and a legalisation (a request raised to keep access that already exists) is labelled as such, with the warning that rejecting it removes the live access. A tenant can also switch on approval from the notification mail: the mail carries one link to a confirmation page that shows the same context, and the decision is taken there, never from the link itself. While a tenant enforces SSO the link is not offered and a link already mailed stops working, so the decision always goes through the tenant's identity provider. Switching approval from the mail off has the same effect on links already sent: they stop working at once, and the task stays open in the inbox. Switching it back on revives a link that has not yet expired. 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. A step waiting on someone who may decide but has no RapidValue login yet carries a No login yet badge, on the request's chain, on the decision task and in the active-approvals view, and the Platform Advisor raises a finding to invite that person or reassign the task. The step is not rerouted and no login is created for them.
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 four-eyes guard, and its own SoD check — there is no blanket approve.
Self-approval handling
Whoever initiated a change may not approve it. When a step's resolved approver turns out to be the requester, the step is not auto-approved: it is rerouted before the task exists, to the tenant's configured fallback for that step (for a manager step, the manager's manager) and otherwise to the IAM team, and it is labelled as a four-eyes fallback. The decide action is also refused server-side for the requester, on-behalf requesters included and administrators using the override included; the inbox hides Approve and says why. Rejecting or withdrawing your own request stays allowed. In a tenant with a single administrator, a change that administrator started waits for a second one. See Access requests.
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. The person a decision is assigned to can also hand an access-request decision to a named person from the Inbox; not to a role, not a task that is not theirs, and not after it is decided.
- Review decided history and export it as a comma-separated-values (CSV) file for an audit engagement.
A Proposals tab suggests, from the tenant's own data, which rights should be requestable (and assigns no owner by itself), and an approval chain per risk level: for low-risk rights, manager only where the owner step approved nearly everything it was asked in the last 90 days; for high and critical rights that no rule routes yet, manager, owner and security team. A chain proposal opens in the approval-rule editor and is saved there; a requestability proposal can be dry-run before it is applied, and each right it changes is audited. An administrator can dismiss a requestability proposal (with Undo) and bring it back from the Dismissed view; both are recorded in the configuration history. A dismissal holds only while the right draws the same proposal for the same reason: when the facts change, for instance an owner appears, the new proposal shows again.
The Inbox's To decide tab also has a Waiting longest view across every decision kind, grouped per person who holds the decisions, oldest queue first, with remind and reassign. A manager can remind there too, but only people in their own team, and sees only the decisions that team holds.
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 is surface plus reminders plus manual: overdue and due-soon cues, manual reassign, and an automatic reminder mail to an approver whose task is seven days past its due date (then at most one every seven days, three in total, and not on a day a digest already went out). There is no automatic escalation to another approver — 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.