> 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/plan-and-scope-a-campaign.md). # Plan and scope a campaign Choose the campaign type, configure the definition and scope it — the two types, why risk is a filter rather than a type, and the fields that decide whether anyone is ever notified. ## What this is, and when you need it An access certification campaign asks named people to look at access that already exists and say, item by item, whether it is still justified — then records what they said. It exists because grants accumulate: nothing revokes access when the reason for it quietly expires, so periodically someone who knows the person, or knows the application, has to be asked. This page covers everything you decide **before** a preview exists: the type, the definition fields, the scope, and the reviewer steps. Running the preview and promoting it into a live campaign is [Preview and launch a campaign](/administration-guide/governance/certification/preview-and-launch.md), and nothing reaches a reviewer until you get there. The two type-specific pages cover only what differs about their type; neither repeats this sequence. The objects underneath all of it are [The certification model](/administration-guide/governance/certification/certification-model.md). ## At a glance | | | | ------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------- | | **You will end up with** | A saved `CERTIFICATION` row, scoped and with at least one reviewer step — ready to preview, with nothing sent to anyone | | **Where** | `/webconsole/access-certifications` for the list, `/webconsole/access-certification-edit?id=&tab=` for the tabbed editor | | **You need first** | A decision on which of the two campaign types; at least one reviewer step; an **Email Template** on the definition, or nobody is notified | | **Takes** | 30 to 60 minutes to configure | | **Reversible** | Yes. Nothing here mails anyone or starts a workflow — that is [launch](/administration-guide/governance/certification/preview-and-launch.md) | ## Before you begin You need a certification definition saved before you can preview it, and you need at least one reviewer step — a certification with no reviewers is refused at initialization with *"Certification was not started because reviewers are empty"*. {% hint style="info" %} **The editor is one tab until you save.** Every tab except **Configurations** is hidden until the record has an id, so the first save is what unlocks scope, reviewers and expiration. Save early and expect the screen to grow. {% endhint %} Two boundaries earn their keep while you are still building. **Save the definition with `Status` = `Inactive`**, stored in `CERTIFICATION.STATUS`: an inactive definition is a checkpoint you can preview and inspect. And **leave `Scheduled Interval` blank until the preview is right**, because a schedule (`CERTIFICATION.SCHEDULE_TYPE`) makes the batch scheduler start previews on its own. Everything else in [Change configuration safely](/administration-guide/start/change-safely.md) applies unchanged. ## Configure and scope it {% stepper %} {% step %} ### Choose the type **Configurations** tab (`/webconsole/access-certification-edit?id=`). Set **Type of Certification** first — it is stored in `CERTIFICATION.CERTIFICATION_TYPE`, it decides which type-specific tab appears, and **the control is disabled once the record has been saved**. Changing your mind means a new definition. | Stored value | Screen label | Pick it when the obligation is | The reviewer sees | | --------------------------- | ------------------------- | ------------------------------------------------------------------------------------ | ----------------------------------------- | | `USER_CERTIFICATION` | User certification | *per person* — a department, contractors, everyone reporting to a named manager | One user and all of that user's access | | `APPLICATION_CERTIFICATION` | Application certification | *per system* — SOX scope on the finance ERP, a review driven by an application owner | One entitlement and everyone who holds it | {% hint style="warning" %} **There is no risk campaign type.** Risk narrows *either* type through the **Risk** tab's membership risk score, so "review the risky access in Finance" is a user certification with a threshold set, not a type of its own. A third type, `RISK_EVENT_DRIVEN_CERTIFICATION`, existed up to and including 2026.9.0 and was removed in 2026.9.1 — it was a user certification plus an identity-risk filter, and the identity-risk filter itself was retired at the same time. An export taken from an older release can still carry the value; a definition created on 2026.9.1 cannot. See [Access certification and risk](/administration-guide/risk/certification.md). {% endhint %} Then the fields that matter beyond name and description: | Field | Column | Note | | -------------------------- | ---------------------------- | -------------------------------------------------------------------------------------- | | Name | `NAME` | Required, 50 characters | | Description | `DESCRIPTION` | Optional, 1024 characters | | Status | `STATUS` | `Active` / `Inactive` | | Scheduled Interval | `SCHEDULE_TYPE` | `Annually`, `Semi-annually`, `Quarterly`, `Monthly`. Blank means manual only | | Reference Start Date | `START_DATE` | Anchor the schedule counts from | | Email Template | `MAIL_TEMPLATE_ID` | **Blank means reviewers are never notified at launch** | | Manager of Access Review | `CERTIFICATION_MANAGER` rows | Recipients of the scope and complete reports; also who may extend, expire and delegate | | Membership Tags to Exclude | `CERTIFICATION_TAG` rows | Drives the `ENTITLEMENT_EXCLUDED_TAG` exclusion | | Allow Bulk Approval | `ALLOW_BULK_APPROVAL` | Lets reviewers decide a whole user or whole entitlement in one click | {% hint style="danger" %} Launch notifications are sent only when **Email Template** holds a value. With it blank the campaign launches, review items are created, Activiti tasks are assigned — and not one reviewer is told. Nothing in the UI warns you, and there is no failed-notification audit record to find afterwards, because nothing was attempted. Set it before the first real launch, then confirm on the first launch that the audit log carries `SEND_CERTIFICATION_NOTIFICATIONS`; that event is the only positive proof the mail path ran. `ACCESS_CERTIFICATION_ACCEPTED` and `RESOURCE_CERTIFICATION_NOTIFY` are shipped starting points, listed in [Shipped mail templates](/administration-guide/reference/shipped-mail-templates.md). {% endhint %} **Allow Bulk Approval** ships off, and the product argues against it on the screen itself. Its help text reads *"Reviewers can approve or revoke all access items for a user or entitlement in one click, without drilling into individual items"*, and turning it on raises a red disclaimer headed *"Bulk approval is risky - enable at your own risk."* Everything decided that way is marked in the evidence — see [Operate a live campaign](/administration-guide/governance/certification/operate-a-live-campaign.md). Leave it off unless someone has accepted that trade in writing. {% endstep %} {% step %} ### Set the risk filter, or leave it off **Risk** tab. This tab is present on **both** campaign types — it is not type-specific, and it has not been since risk became a scope modifier. One control decides scope: **Membership risk score**, stored in `CERTIFICATION.MIN_MEMBERSHIP_RISK`. It is inclusive — an access grant scoring at or above the number is reviewed, everything below is skipped as acceptable — and it is off by default, in which case every access item in the configured scope enters the cycle. The tab also holds **Enable Beta Features** and, behind it, the auto-certify **Automation Rules**. All of it, including why the identity-level threshold no longer exists, is on [Access certification and risk](/administration-guide/risk/certification.md). Set the threshold there and come back. {% endstep %} {% step %} ### Define the scope on the type-specific tab **Select Users** or **Applications**. This is the only step that differs by type: * [Create a user campaign](/administration-guide/governance/certification/create-a-user-campaign.md) * [Create an application campaign](/administration-guide/governance/certification/create-an-application-campaign.md) Keep the first run narrow. Scope is validated on save, and the failure comes back as a specific error code, not a generic one: | Type | Rejected when | Error code | | --------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------ | -------------------------- | | `USER_CERTIFICATION` | No selection mode was chosen; or the mode is `EXTENDED_SEARCH` and no saved search was picked; or the mode is set but nothing was selected | `NO_TARGET_USERS_SELECTED` | | `APPLICATION_CERTIFICATION` | No application **and** no role **and** no group was selected | `NO_ENTITLEMENT_SELECTED` | Validation runs in a fixed order, and scope is only checked on a record that already has an id: name, then type, then status, then — for a saved record — reviewers, then the type scope, then the risk threshold range, then the auto-certify maximum, then each reviewer's reminder fields, then the extension cap. The first failure is the one you are shown, so a form with several gaps takes several saves. {% endstep %} {% step %} ### Define reviewer steps and the expiration policy **Reviewers** and **Expiration Policy** tabs. Reviewer steps decide who is asked and how long they have; the expiration policy decides what happens to an item nobody decided. Both are on [Configure the review workflow](/administration-guide/governance/certification/configure-the-review-workflow.md), which also explains why the reminder cadence you configure here does nothing until two batch tasks are enabled. {% endstep %} {% endstepper %} ## Verification | What you changed | Evidence | | ------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Saved a definition | Audit `MODIFY_CERTIFICATION` for a **new** definition and `CREATE_CERTIFICATION` for an **edit** — OpenIAM emits the two the wrong way round when saving a certification, so search for either; then re-open the definition and confirm the fields you set | | Scoped it | The **Preview** tab becomes available. It appears only once the record is saved, has at least one reviewer, and has a type scope chosen — so its presence is itself the check that all three are done | ## When it goes wrong | Symptom | Cause | Fix | | ------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------ | | Only the **Configurations** tab is visible | The record has never been saved | Save it; the remaining tabs appear | | **Type of Certification** cannot be changed | Expected — the control is disabled once the record has an id | Create a new definition; the type decides the scope tables and cannot be migrated | | The **Preview** tab is missing on a saved record | No reviewer step, or no type scope | Complete the **Reviewers** tab and the type-specific tab | | Save fails with `NO_TARGET_USERS_SELECTED` | `USER_QUERYING_MODE` is null, or set to `EXTENDED_SEARCH` with a blank `EXTENDED_SEARCH_ID`, or `CERTIFICATION_TARGET` is empty | Complete the **Select Users** tab — see [Create a user campaign](/administration-guide/governance/certification/create-a-user-campaign.md) | | Save fails with `NO_ENTITLEMENT_SELECTED` | No application, role or group selected | Complete the **Applications** tab | | An imported definition reads `RISK_EVENT_DRIVEN_CERTIFICATION` | It predates 2026.9.1 | Re-create it as a user certification and set the membership risk score on the **Risk** tab | | The audit log shows `CREATE_CERTIFICATION` for an edit and `MODIFY_CERTIFICATION` for a new definition | OpenIAM picks the two audit actions the wrong way round when saving a certification: a definition that already has an id is audited as a create, one without an id as a modify | Do not distinguish create from edit by audit action for certifications; use `CERTIFICATION.CREATE_DATE` and `MODIFY_DATE` instead | ## The tabs, and when each appears | Tab | Appears when | | ----------------------------------- | ------------------------------------------------------------ | | **Configurations** | Always | | **Risk** | Always — on both campaign types | | **Applications** / **Select Users** | Record saved; whichever matches the type | | **Reviewers** | Record saved | | **Expiration Policy** | Record saved | | **Preview** | Record saved, at least one reviewer, and a type scope chosen | | **History** | At least one campaign has been launched | | **Dashboard** | At least one campaign has been launched | The active tab is held in the URL as `?tab=`, so a runbook can link straight at the tab it means. {% hint style="info" %} **Preview** and **History** are the two tab labels that are hard-coded English in the product rather than translated, so they read the same in every locale. That is a known defect, not a deployment problem. {% endhint %} ## Routes | Screen | Route | | -------------------------------- | --------------------------------------------------------------------- | | Certification list | `/webconsole/access-certifications` | | Certification (new) | `/webconsole/access-certification` | | Certification (edit, tabbed) | `/webconsole/access-certification-edit?id=&tab=` | | One user's certification history | `/webconsole/user-certification-history?id=` | All three Webconsole certification routes render the same screen; the `tab` query parameter selects which tab opens. ## Related * [Preview and launch a campaign](/administration-guide/governance/certification/preview-and-launch.md) — the only route to a live campaign * [The certification model](/administration-guide/governance/certification/certification-model.md) — the tables behind every object named here * [Configure the review workflow](/administration-guide/governance/certification/configure-the-review-workflow.md) — the steps that resolve, and the reminders that do not fire by default * [Access certification and risk](/administration-guide/risk/certification.md) — the Risk tab in full * [Enumerated values](/administration-guide/reference/enums.md) — campaign types, preview statuses and every exclusion reason *Applies to OpenIAM 2026.9.1. Last reviewed 14 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/plan-and-scope-a-campaign.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.