> For the complete documentation index, see [llms.txt](https://docs.openiam.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.openiam.com/administration-guide/governance/certification/the-reviewer-experience.md). # What your reviewers see What your reviewers actually see — the decision cart, bulk gates, comparison, the SoD block and the submit disclaimer — and which of your settings changes it. ## What this is, and when you need it You configure a campaign; somebody else does the work. This page is the reviewer's screen described for the **administrator** — so you can brief reviewers before a launch, answer "why can't I click that?", and understand which of your settings changes what they see. It is not the end-user instructions. Reviewers who just need to get through their queue should be sent to [Access reviews](/end-user-guide-for-selfservice/access-reviews.md) in the SelfService guide. Risk on the reviewer screen — the score, the bands, the drift arrow, the factor breakdown — is a section of its own and is not repeated here: see [Reading risk on the reviewer screen](/administration-guide/risk/reviewer-experience.md). So is **Caddie — Access Review Assistant**: the sparkles button beside the decision toggle that opens a read-only context panel about one row, and the **History** column that opens an item's audit trail. Both are described in [Caddie — Access Review Assistant](/administration-guide/caddie.md); this page notes only where they sit and which setting switches the panel on. ## Where reviewers go Reviewers meet the work in SelfService, at `/selfservice-v2/uar/campaigns`, with the campaign id as a path segment — `/selfservice-v2/uar/campaigns/`. The landing page is headed **Certifications**, with *"Review and certify user access across the certification campaigns assigned to you"* beneath it. A reviewer who has never been assigned a campaign sees **No Campaigns Yet**. {% hint style="warning" %} **The shipped reviewer mail link does not go here.** The mail template ships pointing at `/selfservice/uar/campaigns/` — the path without `-v2` — which serves the previous reviewer screen, not the one described on this page. A reviewer who clicks through from email therefore lands somewhere that looks nothing like these instructions. Until the shipped template is repointed, either send reviewers the `/selfservice-v2/` link directly or edit **Email Template** on the certification to use it. See [Configure the review workflow](/administration-guide/governance/certification/configure-the-review-workflow.md#the-reminder-and-escalation-mail-templates). {% endhint %} {% hint style="info" %} There is no "send a reminder now" button anywhere in the product, for you or for them. Reminders are configured per reviewer step and are delivered by a batch task that ships disabled — see [Configure the review workflow](/administration-guide/governance/certification/configure-the-review-workflow.md). {% endhint %} ## The campaign list Two filter rows sit above the campaigns, counting the same campaigns two different ways. | Filter | Buckets | | ---------- | ------------------------------------- | | **Status** | In Progress, Not Started, Completed | | **Due** | Past Due, 1-5 Days Left, 5+ Days Left | The **Due** buckets are fixed: "urgent" means five days or fewer, and it is not configurable. Campaigns past their date raise a banner — *"{n} campaign(s) past their due date need your attention."* Each campaign card carries `{done} / {total} reviewed`, chips for **Overdue**, **Extended**, **Open** and **Ready to submit**, a role chip of **Reviewer**, **Manager** or **You**, and one action button — **Start**, **Resume**, **Submit now** or **Manage**. ## Inside a campaign Up to three tabs, depending on who the reviewer is: | Tab | Who sees it | What it lists | | -------------------- | ------------------------------------------------------------------- | ---------------------------------------------------------------------------------- | | **Entitlement View** | Every reviewer | One row per entitlement, with how many of its holders are done | | **User View** | Every reviewer | One row per user, with how many of their entitlements are done | | **UAR Manager View** | Only users listed as **Manager of Access Review** on the definition | Every item with its **Current Reviewer** and **Request Status**, plus **Delegate** |
A campaign open on User View, with the Entitlement View and User View toggle above the list, the certification progress bar reading 0 of 1705 decided, and filter chips for All, Pending and Certified
{% hint style="warning" %} **A campaign manager cannot decide.** The Manager View is read-only for certify and revoke — a manager can watch progress and delegate items to someone else, but cannot certify or revoke on a reviewer's behalf. If you put a person on **Manager of Access Review** expecting them to clear a stuck queue, they cannot; they can only delegate it to somebody who can. {% endhint %} Progress is reported as three numbers, and the distinction matters when a reviewer says they are finished: `{n} submitted` — saved to the server, `{n} pending` — *unsaved, still in their cart*, and `{n} not yet reviewed`. ## The decision cart This is the part that most surprises administrators. **A reviewer's decisions are not saved as they are made.** Certify and revoke mark items in a local cart, a footer bar counts `{n} pending decisions`, and nothing reaches the server until the reviewer opens **Review & Submit** and submits. Consequences worth knowing before you field the question: * A campaign whose counters have not moved is not necessarily a campaign nobody has worked on. The work may be sitting unsubmitted in someone's browser. * **Discard all** exists, and it warns it *"cannot be undone"* — but it only clears unsubmitted decisions. Anything already submitted is untouched. * Submitted decisions cannot be changed. Items already sent show *"Decision already submitted — cannot be changed"*. The submit step carries a **Disclaimer of Responsibility**: *"By submitting, you confirm that you have reviewed the access listed and that your decisions are accurate to the best of your knowledge. Submitted decisions are permanently recorded in the audit log with your name and timestamp and may be reviewed by your security, compliance, or audit teams."* Large submissions are processed in the background, with `{n} of {m} decisions saved` while they run. A reviewer who submits again while the previous submission is still saving is refused rather than double-counted — *"Your previous submission is still being saved. Please wait until it finishes before submitting again."* From OpenIAM 2026.10.1, a submission is accepted only from a reviewer who holds the review task for **every** item in it — as the assigned reviewer, or as one of the candidate reviewers on a multi-approver step. Delegation and escalation move the task along with the items, so a delegate or an escalation target qualifies. If any item in the submission fails this check, or can no longer be matched to a review task, **the whole submission is rejected and nothing in it is saved**: no decision, no counter change and no deprovisioning. The same check applies to each part of a bulk submission. {% hint style="warning" %} A rejected submission does not show an error on the reviewer's screen, because submissions are saved in the background. The audit log records it as a failed `MAKE_ACCESS_REVIEW_ITEM_DECISION` event with the reason *"User … is not authorized to decide access-review item …"*. See [Diagnose a stalled campaign](/administration-guide/governance/certification/diagnose-a-stalled-campaign.md#when-it-goes-wrong). {% endhint %} ## Deciding The two decisions are **Certify** and **Revoke**. There is no third option, no "abstain" — an item left alone stays undecided and is settled by the expiration policy when the campaign ends. A per-decision note is **optional**, placeholder *"Add an optional note for this decision"*. If your control requires a justification for every revocation, the product will not enforce it for you; say so in the reviewer briefing and check the `REVIEW_NOTE` column afterwards. **Delegation is the one action that does require a comment.** Items the campaign's automation rule pre-approved carry an **Auto** chip — *"Pre-approved by the system — this item's risk score is below the campaign's auto-approval threshold"*. They are shown to reviewers by default; the alternative, hiding them, exists in the model but is not offered in the UI. ## Bulk decisions, and the two gates Bulk exists at two different grains, and they are gated differently. **Row selection** is always available: the reviewer ticks rows and a bar appears with the selected count, a breakdown of undecided, certified and revoked, and **Clear selection**. What that bar offers, though, depends on your setting — and not symmetrically: | Control | Appears | | ---------------------------- | ---------------------------------------------------------------------------------------- | | **Revoke selected** | **Always.** It is not gated by Allow Bulk Approval | | **Certify selected** | Only when **Allow Bulk Approval** is on | | `{n} need individual review` | Only when **Allow Bulk Approval** is on, and only when the selection contains such items | {% hint style="warning" %} **Turning Allow Bulk Approval off does not stop bulk revocation.** It removes bulk *certify* and leaves bulk *revoke* in place, so a reviewer can still remove access from many rows in one action on a campaign where you believed bulk decisions were disabled. If that is not what you intended, the control is scope and reviewer briefing, not this setting. {% endhint %}
Four rows selected on a campaign with Allow Bulk Approval off: the bar offers only Revoke selected and Clear selection, with counts reading 4 undecided, 0 certified, 0 revoked
Where bulk certify *is* offered, it carries a safety gate you did not configure and cannot turn off: high-risk, critical-risk and SoD-conflicted items are **excluded from it** and must be decided one at a time. The bar reports `{n} need individual review`, and the confirmation dialog repeats how many were held back. **Whole-user or whole-entitlement** bulk — one click decides every item for that person or that entitlement — appears **only when you set Allow Bulk Approval on the definition**. It presents as **Bulk Approval Mode** and warns the reviewer that decisions are applied *"without reviewing items individually"*. {% hint style="danger" %} `ALLOW_BULK_APPROVAL` is copied onto the campaign at launch. **Turning it off on the definition does not turn it off on a running campaign** — you cannot close that door mid-flight. The only lever on a live campaign is to expire it. Everything decided that way is marked in the evidence, and the complete report's `BULK_APPROVAL_RISK` column reads *"YES - reviewed via bulk approval (RISKY: items not reviewed individually)"*. See [Campaign history and evidence](/administration-guide/governance/certification/campaign-history-and-evidence.md). {% endhint %} The revoke confirmation is explicit that this is not a paper exercise: *"Revoking will trigger deprovisioning for the selected access once submitted."* ## Comparison A reviewer facing dozens of entitlements has no context for judging any single row. **Compare** supplies it, against either another user or a previous campaign launch. It is available in every campaign type with nothing to enable, though a deployment can hide the button with `openiam.ui.webconsole.user.compare.with.button.show`. The two baselines are offered as a choice the moment the reviewer opens it, described on screen as *"Side-by-side peer entitlement diff"* and *"Prior outcomes and access that came back"*.
The Compare entitlements dialog offering two baselines, Compare with another user and Compare with another campaign, with a user picker beneath
The mechanics, the four audit counts, the attribute-level diff and its limits are on [Operate a live campaign](/administration-guide/governance/certification/operate-a-live-campaign.md#what-a-reviewer-can-compare-against). The one thing to tell reviewers: it covers **direct role and group memberships only**, so a clean diff is not proof that nothing else changed. ## Segregation of duties can block a decision Where a reviewed user has an open SoD violation, their rows are blocked outright: *"This user's access cannot be approved or revoked until all SoD violations are resolved"*, with a **Resolve Violations** link. The reviewer works the violation to a resolution — or skips the policy, which delegates it to the next approver — before their decisions on that user can be submitted. If reviewers report that a campaign will not let them submit, this is the usual reason, and the **Review & Submit** screen names it: *"{n} SoD policies still in review — resolve them before submitting."* ## Focus A **Focus | List** toggle, called **Priority Queue** in earlier releases, sorts a reviewer's items by what to do with them: **Needs your attention**, **Same as last time**, **Auto-certified** and **Everything else**. Each item that needs attention carries short reasons, such as *SoD violation* or *Revoked before, now back*, and a line at the top counts the groups. For a large queue this is the difference between a reviewer reading the top of the list and reading the part that needs judgement. Reviewers who make decisions start in Focus; it is still worth naming in a briefing. Focus is offered only in campaigns launched with **Enable Beta Features** on. It never recommends a decision, and its group buttons follow the same bulk rules as the rest of the screen. What each group and reason means is on [Reading risk on the reviewer screen](/administration-guide/risk/reviewer-experience.md#reviewer-priority-queue). ## What your settings change | You set | The reviewer gets | | --------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Email Template** blank | No notification at all — they never learn the campaign exists | | **Allow Bulk Approval** on | **Certify selected** on the row-selection bar, and **Bulk Approval Mode** for whole-user and whole-entitlement decisions. **Revoke selected** is there either way | | **Membership risk score** | A smaller queue; low-risk grants never appear | | **Automation Rules** on | Pre-approved items carrying the **Auto** chip | | **Enable Beta Features** on | The risk shields and factor breakdowns described in [Reading risk on the reviewer screen](/administration-guide/risk/reviewer-experience.md) | | **Enable Caddie — Access Review Assistant** on, beneath Beta features | A sparkles button in the **Decision** column of every row still open at the reviewer's step, opening the read-only [Caddie panel](/administration-guide/caddie/the-caddie-panel.md). Never on the Manager View | | Multiple reviewer steps | A later reviewer sees *"Items will appear here once previous review steps have been completed"* until the earlier step finishes | | **Manager of Access Review** | That person gets **UAR Manager View** and delegation — but not the ability to decide | ## Related * [Configure the review workflow](/administration-guide/governance/certification/configure-the-review-workflow.md) — who is asked, for how long, and what happens when nobody answers * [Operate a live campaign](/administration-guide/governance/certification/operate-a-live-campaign.md) — watching it, and what a revoke decision actually does * [Reading risk on the reviewer screen](/administration-guide/risk/reviewer-experience.md) — the risk elements of the same screen * [Caddie — Access Review Assistant](/administration-guide/caddie.md) — the context panel beside each decision, and the audit trail of an item * [Campaign history and evidence](/administration-guide/governance/certification/campaign-history-and-evidence.md) — how the decisions come back out * [Access reviews](/end-user-guide-for-selfservice/access-reviews.md) — the reviewer's own guide *Applies to OpenIAM 2026.9.1. Last reviewed 27 September 2026.* --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.openiam.com/administration-guide/governance/certification/the-reviewer-experience.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.