> 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/caddie/reviewer-details-templates.md).
# Reviewer details templates
Choose which user, role and group details reviewers see in a certification's campaigns — the Reviewer details templates section, the three shipped defaults field by field, how to build your own, and w
## What this is, and when you need it
While reviewing a campaign, a reviewer can open two read-only dialogs: **user details**, from the name of a reviewed user or of their manager, and **entitlement details**, from the name of a role or group. The **User information** and **Entitlement information** blocks of Caddie — Access Review Assistant show the same rows. What all of them show is not fixed. Each certification names one page template per object type, and the dialogs and blocks render exactly the fields an administrator placed on that template, in that order, with the reviewed object's values.
You need this page when the shipped templates do not show what your reviewers need to decide: a cost centre, a contract end date, a custom attribute that says which system an entitlement really belongs to, or simply fewer rows. If the defaults are fine, you need nothing here; the three templates ship seeded and work without configuration. This is **not** a beta feature and does not depend on the Caddie switch: every campaign has the dialogs, and they render through these templates.
## At a glance
| Setting | Where | Default | Reaches a campaign |
| -------------------------- | ---------------------------------------------------------------------- | -------------------------------------- | --------------------------------------- |
| **User details template** | Certification → **Configuration** tab → **Reviewer details templates** | `CERT_REVIEW_USER_TEMPLATE` (default) | Copied at launch |
| **Role details template** | Same section | `CERT_REVIEW_ROLE_TEMPLATE` (default) | Copied at launch |
| **Group details template** | Same section | `CERT_REVIEW_GROUP_TEMPLATE` (default) | Copied at launch |
| The templates' content | Webconsole → **Administration** → **Page Templates** | Seeded | Read every time a dialog or block opens |
## Before you begin
* Administrator access to the Webconsole with the **Access Certification** and **Page Templates** menus.
* If you are adding a custom attribute, it exists as a metadata element already. Creating one is described in [Build a page template](/administration-guide/identities/page-templates-and-custom-fields.md).
## Choose the templates for a certification
{% stepper %}
{% step %}
Go to Webconsole → **Access Control** → **Access Certification** and open the certification.
{% endstep %}
{% step %}
On the **Configuration** tab, scroll to the bottom. The **Reviewer details templates** section is the last one on the tab and is collapsed by default; expand it. Its helper text reads: *Page templates that define which user, role and group details reviewers see in this certification's campaigns. Leave a picker on the default to use the built-in template; the choice is copied onto each campaign when it launches.*
{% endstep %}
{% step %}
Pick a template in any of the three pickers, or leave it on the default.
{% endstep %}
{% step %}
Choose **Save**.
{% endstep %}
{% endstepper %}
### The three pickers
| Picker | Lists | Drives |
| -------------------------- | --------------------------------------- | ---------------------------------------------------------------------------------------------------------- |
| **User details template** | Page templates of type `USER_TEMPLATE` | The user details dialog and the **User information** block |
| **Role details template** | Page templates of type `ROLE_TEMPLATE` | The entitlement details dialog and the **Entitlement information** block, for items whose access is a role |
| **Group details template** | Page templates of type `GROUP_TEMPLATE` | The same two surfaces, for items whose access is a group |
Each picker lists only the templates of its own type. The seeded default comes first with the suffix **(default)**; the others follow in alphabetical order. A stored id whose template no longer exists shows as the id with the suffix **(missing)**.
Leaving a picker on the default stores **no** template id on the certification. The certification keeps meaning "whatever the default template is", so it never pins today's default and a later change to the default template is picked up automatically.
On save, a chosen template must still exist and must be of the matching type. If it does not, because it was deleted in the meantime or because a request through the REST API put a role template id into the user picker, the save is rejected with the error code `TEMPLATE_IS_NOT_DEFINED`.
### How the value reaches a campaign
* The three ids are saved on the certification and **copied onto each campaign at launch**.
* A campaign keeps the templates it launched with. Changing a picker later does not change the dialogs of a campaign already running.
* Edits to the **content** of a template are visible right away, in running campaigns too, because the template is rendered every time a dialog or block opens.
## The shipped default templates
Three page templates are seeded in the `openiam` database. They appear under Webconsole → **Administration** → **Page Templates**, and are edited there like any other template, for example at `/webconsole/editPageTemplate?id=CERT_REVIEW_USER_TEMPLATE`.
| Template id | Name | Type |
| ---------------------------- | ------------------------------------ | ---------------- |
| `CERT_REVIEW_USER_TEMPLATE` | Certification review - user details | `USER_TEMPLATE` |
| `CERT_REVIEW_ROLE_TEMPLATE` | Certification review - role details | `ROLE_TEMPLATE` |
| `CERT_REVIEW_GROUP_TEMPLATE` | Certification review - group details | `GROUP_TEMPLATE` |
Unlike the default user, role and group templates, these three are bound to **no URI pattern and no metadata type**. The regular create and edit pages never resolve them, so adding or removing a field on a certification review template changes the reviewer dialogs and Caddie, and nothing else. The competing-template trap described in [Build a page template](/administration-guide/identities/page-templates-and-custom-fields.md#binding-and-the-competing-template-trap) does not apply to them.
{% hint style="danger" %}
**Do not delete the seeded templates.** Every campaign whose certification left a picker on the default renders with them. If one has been deleted, re-apply its seed script, `schema//openiam/2026.9.2.0/V2026.9.2.0.008__OE-5141.sql` in the `conf` repository. The script is idempotent and recreates the three templates in their shipped state, so any customization made to them is reset.
{% endhint %}
### Default user details template
On the **Page Templates** screen the fields carry their technical names: *Display Name*, *User Title*, *Employee Type* and so on. The label a reviewer reads is the field's display name in their language, which for the seeded templates is the first column below. Fields of `CERT_REVIEW_USER_TEMPLATE`, in display order:
| Label | Field id | Shown as |
| --------------------- | ------------------------- | --------------------------------------------------------------------------------------------- |
| Name | `USER_DISPLAY_NAME` | The user's display name |
| Title | `USER_TITLE` | |
| Employee type | `USER_EMPLOYEE_TYPE` | The localized name of the employee type |
| User type | `USER_USER_TYPE` | The localized name of the user type |
| Status | `USER_STATUS` | The user status, for example `ACTIVE` |
| Account status | `USER_SECONDARY_STATUS` | The account status, for example `ENABLED` |
| Login | `USER_PRIMARY_LOGIN` | The login on the default OpenIAM managed system, or the user's first login when there is none |
| Email address | `USER_SIMPLE_EMAIL` | The primary email address, or the first one |
| Phone | `USER_SIMPLE_PHONE` | The cell phone, or the first phone, as `country area number ext. extension` |
| With the organization | `USER_START_DATE` | The tenure, as *With the organization since {date} ({n} years, {m} months)* |
| Organizations | `USER_SHOW_ORGANIZATIONS` | One row per organization the user belongs to, as `[type] name`, sorted by name |
| Manager | `USER_SELECT_SUPERVISOR` | The primary supervisor first, then any other supervisors |
| Location | `USER_LOCATION_NAME` | |
| Employee ID | `USER_EMPLOYEE_ID` | |
| Previous position | `USER_PREVIOUS_POSITION` | |
### Default role and group details templates
`CERT_REVIEW_ROLE_TEMPLATE` and `CERT_REVIEW_GROUP_TEMPLATE` carry the same fields in the same order.
| Label | Field id (role / group) | Shown as |
| ------------------- | ---------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------- |
| Name | `ROLE_NAME` / `GROUP_NAME` | |
| Type | `ROLE_TYPE` / `GROUP_TYPE` | The localized name of the role or group type |
| Description | `ROLE_DESCRIPTION` / `GROUP_DESCRIPTION` | |
| Created | `ROLE_CREATED_DATE` / `GROUP_CREATED_DATE` | The date the entitlement was created |
| Created by | `ROLE_CREATED_BY` / `GROUP_CREATED_BY` | The display name of the user who created it |
| Owner | `ROLE_OWNER` / `GROUP_OWNER` | The owner. A group principal is marked **(group)** |
| Administrator | `ROLE_ADMIN` / `GROUP_ADMIN` | The administrator. A group principal is marked **(group)** |
| Approvers | `ROLE_APPROVERS` / `GROUP_APPROVERS` | The approval chain: one line per level, with the approver's name and association type |
| Resources | `ROLE_RESOURCES` / `GROUP_RESOURCES` | The resources the entitlement grants, sorted by name: the first 10, then *and {n} more* |
| Application | `ROLE_MANAGED_SYS` / `GROUP_MANAGED_SYS` | The managed system the entitlement belongs to |
| Application owner | `ROLE_APPLICATION_OWNER` / `GROUP_APPLICATION_OWNER` | The owner of the application's resource, or *This application has no owner* when the application exists and nobody owns it |
| Risk classification | `ROLE_RISK` / `GROUP_RISK` | The entitlement's risk level |
## Build your own template
To show reviewers something the defaults do not, either edit a seeded template or create one of the right type and select it on the certification.
{% stepper %}
{% step %}
Go to Webconsole → **Administration** → **Page Templates** and choose **Create New Template**. Pick the user, role or group template type and leave the URI patterns empty: the template is selected by the certification, never resolved by URL.
{% endstep %}
{% step %}
In **Template Fields**, add the fields to show, in the order to show them. Every built-in field id in the tables above is available to any template of its type; custom fields are added the same way as on any other template.
{% endstep %}
{% step %}
Give each field the label reviewers should read. The label comes from the field's display name in the reviewer's language and falls back to the field's technical name.
{% endstep %}
{% step %}
Save the template, then select it in the certification's **Reviewer details templates** section and save the certification. Campaigns launched from then on render with it.
{% endstep %}
{% endstepper %}
The reviewer screens only **display** a template. Field rules (hide, show, disable, require), validation scripts and required flags are not applied, and a reviewer cannot change a value.
## What reviewers see
* **Rows without a value are omitted.** A field that has no value for the reviewed user, role or group is not sent at all, so a dialog never shows an empty row. The one exception is **Application owner**, which reads *This application has no owner* when the application exists and nobody owns it, because that is a fact a reviewer needs.
* **Custom attributes** render as label and value rows like the built-in fields. An attribute that is not public and whose resource the reviewer is not entitled to is left out of the response altogether, not merely hidden. Delegation-filter attributes (`DLG_FLT*`) are never shown.
* **The template itself must be visible to the reviewer**: public, or backed by a resource the reviewer is entitled to. Otherwise the dialog cannot load.
* **Labels are localized** from the field's display names. The seeded templates carry the English label for every configured language, so translate them on the template if your reviewers work in another language.
* **The same people may open them**: campaign administrators, and reviewers who currently review, or have already reviewed, at least one item of that user or entitlement in the campaign. Anyone else is refused, so the details never widen what a reviewer is already entitled to see.
## Verification
Launch a campaign and, as one of its reviewers, click a reviewed user's name. The dialog, titled *Overview about: {name}*, lists exactly the fields of the selected user template that have a value, in template order. Click an entitlement's name for the *Entitlement Details* dialog. If the campaign has Caddie, the **User information** and **Entitlement information** blocks show the same rows.
## When it goes wrong
| Symptom | Likely cause |
| --------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------- |
| A picker shows an id with the suffix **(missing)** | The template the certification stored was deleted. Pick another, or leave the picker on the default |
| Save fails with `TEMPLATE_IS_NOT_DEFINED` | The chosen template no longer exists, or is not of the picker's type |
| A dialog or block shows fewer rows than the template has | Expected: rows without a value are omitted, and non-public custom attributes are filtered by the reviewer's entitlements |
| The dialogs render, but with the shipped fields rather than your template | The campaign launched before you changed the picker. Campaigns keep the templates they launched with |
| A dialog reads *No details template is configured for this campaign. Ask an administrator to restore the default template.* | The template the campaign launched with has been deleted **and** the seeded default of that type is missing. Re-apply the seed script above |
| The template was deleted but dialogs still render | Expected: the screens fall back to the seeded default of the same type and log a warning |
| A reviewer gets an error with **Retry** on every dialog | The reviewer is not a current or past reviewer of that user or entitlement in the campaign, or the template is not visible to them |
## Upgrading from the decision-details property
Earlier releases built the reviewer's user details dialog from a fixed set of fields plus the user attributes listed in the system property `org.openiam.workflow.task.decision.details`. The dialogs of the current SelfService reviewer screens no longer read that property: the rows shown are those of the campaign's user details template.
If you listed extra attributes in that property for reviewers, add the same attributes to your user details template, either as custom fields on `CERT_REVIEW_USER_TEMPLATE` or on a template of your own selected on the certification, and they appear in the dialog and in Caddie again. The property still exists and is still honoured where it was read before outside these screens, such as the task decision page and the previous-generation reviewer screens, so it does not need to be removed.
## Related
* [Build a page template](/administration-guide/identities/page-templates-and-custom-fields.md) — creating templates and custom fields in general
* [The Caddie panel](/administration-guide/caddie/the-caddie-panel.md) — the two blocks these templates drive
* [Create a user campaign](/administration-guide/governance/certification/create-a-user-campaign.md) — the rest of the Configuration tab
*Applies to OpenIAM 2026.9.2. Last reviewed 23 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/caddie/reviewer-details-templates.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.
