> 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/create-an-application-campaign.md). # Create an application campaign Scope an APPLICATION\_CERTIFICATION — which managed systems, which entitlements, the three entitlement selection modes, and why an allow-list silently stops covering new access. ## What this is, and when you need it An application campaign asks *"for these applications, is everyone who holds an entitlement still correct?"*. This page covers the **Applications** tab. Type selection, reviewers, preview and launch are on [Plan and scope a campaign](/administration-guide/governance/certification/plan-and-scope-a-campaign.md). ## At a glance | | | | ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **You will end up with** | An `APPLICATION_CERTIFICATION` definition scoped to named managed systems, with an explicit include or exclude list of their roles and groups | | **Where** | `/webconsole/access-certification-edit?id=` → **Applications** tab | | **You need first** | **Type of Certification** already set to `APPLICATION_CERTIFICATION`; the application represented as a managed system; its roles and groups associated with that managed system | | **Takes** | 20 to 40 minutes, plus a preview to confirm owners are populated | | **Reversible** | Yes — but note that switching between the include and exclude modes nulls the other list without warning | ## Before you begin Set **Type of Certification** to `APPLICATION_CERTIFICATION` on the **Configurations** tab first. **"Application" means managed system.** The **Applications** picker is a managed system picker, and the **Application entitlements** list beneath it offers only roles and groups associated with the managed system you named — nothing else, however you search. So an **application** in this campaign type is a **managed system** (`CERTIFICATION_APPLICATION.APPLICATION_ID`), its **entitlements** are the roles and groups whose `MANAGED_SYS_ID` is that managed system, and a role or group with no managed system association is **not** an entitlement of any application and will never appear in an application campaign, however business-critical it is. That last point is the single most common surprise. If a role you expected is missing from the entitlement list, check its managed system association before you check the campaign — see [Connectors and managed systems](/administration-guide/lifecycle/connectors-and-managed-systems.md). If the application is not represented in OpenIAM at all, start from [Review entitlements that live inside an application](/administration-guide/governance/certification/review-application-entitlements.md) instead. ## Scope the entitlements {% stepper %} {% step %} ### Select the applications On the **Applications** tab, pick the managed systems in scope. Each selection writes one `CERTIFICATION_APPLICATION` row. Selecting an application alone is enough to satisfy save validation in the `ALL` and `EXCLUDED` modes. {% endstep %} {% step %} ### Pick one of the three entitlement selection modes The screen offers three mutually exclusive modes. They are a screen construct only — there is no `ENTITLEMENT_SELECTION_MODE` column anywhere, and the tab works out which mode to show from which scope tables hold rows. So you cannot query the mode; you infer it the same way the screen does, from whether `CERTIFICATION_ROLE` / `CERTIFICATION_GROUP` or `CERTIFICATION_ROLE_EXCLUDE` / `CERTIFICATION_GROUP_EXCLUDE` has rows: | Mode | Screen label and help text | Writes | Clears | | ---------- | -------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------- | -------------------------------------- | | `ALL` | *Use all entitlements* — "All entitlements from the selected applications will be included in this certification." | nothing beyond `CERTIFICATION_APPLICATION` | both the include and the exclude lists | | `SELECT` | *Select entitlements* — "Choose specific entitlements from each selected application to include in the certification." | the roles you pick to `CERTIFICATION_ROLE`, the groups to `CERTIFICATION_GROUP` | the two exclude tables | | `EXCLUDED` | *Exclude entitlements* — "All entitlements from the selected applications will be included except those you explicitly exclude below." | the roles you exclude to `CERTIFICATION_ROLE_EXCLUDE`, the groups to `CERTIFICATION_GROUP_EXCLUDE` | the two include tables | {% hint style="warning" %} **Prefer `EXCLUDED` for a recurring campaign.** A new role added to the application next quarter is automatically in scope with `EXCLUDED` or `ALL`, and automatically out of scope with `SELECT` — which means a `SELECT` campaign silently stops covering new entitlements and the gap never appears in a report. If you must use `SELECT`, treat the entitlement list as a maintained artifact with an owner. And because the mode is *derived* from the stored sets, switching mode nulls the other pair on the next change. You cannot have an allow-list and a deny-list at the same time, and no warning tells you the other list was discarded. Decide which one before you start picking. {% endhint %} {% endstep %} {% step %} ### Pick the entitlements, reading Owner and Admin as you go The picker's columns are **Name**, **Description**, **Risk**, **Metadata type**, **Admin** and **Owner**. Read Admin and Owner before you launch, because they are exactly what a reviewer step of type `ENTITLEMENT_OWNER` or `ENTITLEMENT_ADMIN` will resolve against — and an unset owner does not fail loudly, it quietly removes users from the campaign. The list is paged and filterable by name and by risk, and it can be narrowed to roles only or groups only. The **Metadata type** filter offers the union of the `GROUP_TYPE` and `ROLE_TYPE` metadata type groupings — that is the whole vocabulary available in that column. When the managed system has nothing associated with it, the list reads *"Application has no entitlements"*, which is a managed system association problem and not a campaign problem. {% endstep %} {% step %} ### Choose reviewer types that fit an application Application campaigns are usually reviewed by the people who own the system, not by line managers. The reviewer types worth using here are `APPLICATION_OWNER`, `APPLICATION_ADMIN`, `ENTITLEMENT_OWNER`, `ENTITLEMENT_ADMIN` and `SERVICE_ACCOUNT_OWNER`. Each has a matching Stage 2 exclusion reason — `APPLICATION_OWNER_NOT_FOUND`, `APPLICATION_ADMIN_NOT_FOUND`, `ENTITLEMENT_OWNER_NOT_FOUND`, `ENTITLEMENT_ADMIN_NOT_FOUND`, `OWNER_OF_SERVICE_ACCOUNT_NOT_FOUND` — so an unset owner does not fail loudly, it quietly removes users from the campaign. Configuration is on [Configure the review workflow](/administration-guide/governance/certification/configure-the-review-workflow.md). {% endstep %} {% step %} ### Save, then preview and check the exclusions Save validation requires at least one application, role or group to be selected; with all three empty the save is rejected with `NO_ENTITLEMENT_SELECTED`, and the tab says *"Please select Applications."* Then preview, and read the **Review exclusions before launching** tiles on the **Preview** tab. The only `ROLE_EXCLUDED` or `GROUP_EXCLUDED` rows should be the ones you chose — those appear with grain `ACCESS` and category `ACCESS_DROP`, and they are your evidence that an exclusion was deliberate. Any `*_OWNER_NOT_FOUND` count is a data problem to fix before launch. {% endstep %} {% endstepper %} ## Where scope is actually stored Five kinds of scope selection, five tables: | What you selected | Table that stores it | | ------------------- | ---------------------------------------- | | A role, to include | `CERTIFICATION_ROLE` (`ROLE_ID`) | | A group, to include | `CERTIFICATION_GROUP` (`GRP_ID`) | | A user | `CERTIFICATION_TARGET` (`ENTITY_ID`) | | A role, to exclude | `CERTIFICATION_ROLE_EXCLUDE` (`ROLE_ID`) | | A group, to exclude | `CERTIFICATION_GROUP_EXCLUDE` (`GRP_ID`) | Those five tables are the whole of an application campaign's scope. If you are ever unsure what a definition will actually cover, they answer it, and a preview confirms it. ## Is there a shipped CSV transform script? **No.** There is no shipped Groovy transform for application-campaign entitlement import. Two things are sometimes mistaken for one: * **A "certification CSV import"**, if somebody mentions one, would be a *user* list for `USER_CERTIFICATION` and not an entitlement import at all — and the console offers no such control in any case. See [Create a user campaign](/administration-guide/governance/certification/create-a-user-campaign.md). * **The shipped CSV transformation scripts** — `sync/role/csv/CSVRoleSampleTransformationScript_1.0.groovy`, `sync/group/csv/CSVGroupSampleTransformationScript_1.0.groovy`, `sync/resource/csv/CSVResourceSampleTransformationScript_1.0.groovy` and the `BulkRoleEntitlementsUpload_1.0.groovy` / `BulkGroupEntitlementsUpload_1.0.groovy` / `BulkOrgEntitlementsUpload_1.0.groovy` set — belong to **synchronization**, not certification. They load entitlements *into* OpenIAM; they do not scope a campaign. See [Edit a synchronization transformation script](/administration-guide/automation/synchronization-scripts.md). The one certification extension point that does ship as a script is the scope resolver, `bpm/certification/CustomCertificationHelper_1.0.groovy`, referenced by the property `org.openiam.activiti.access.certification.helper.groovy.script`. It overrides one paged `getData` method on the user search — the contract and the upgrade trap are on [Operate certification services](/administration-guide/governance/certification/operate-certification-services.md#the-one-extension-point-the-certification-helper). Use it when the scope you need cannot be expressed by the tabs; see [Create a Groovy script](/administration-guide/automation/manage-groovy-scripts.md). ## Worked example An annual SOX review of the finance ERP, reviewed first by the entitlement owner and then by the application owner, covering every entitlement except two service-account roles: | Field | Value | | -------------------------- | ---------------------------------------------------------------------- | | Type of Certification | `APPLICATION_CERTIFICATION` | | Scheduled Interval | `ANNUALLY` | | Email Template | a shipped campaign-notify template — **not blank** | | Manager of Access Review | the SOX control owner | | Applications | the ERP managed system | | Entitlement selection mode | *Exclude entitlements* | | Excluded entitlements | the two service-account roles, landing in `CERTIFICATION_ROLE_EXCLUDE` | | Reviewer step 0 | `ENTITLEMENT_OWNER` | | Reviewer step 1 | `APPLICATION_OWNER` | Before launching, confirm on the entitlement picker that **Owner** is populated for every entitlement in scope. Any blank Owner becomes an `ENTITLEMENT_OWNER_NOT_FOUND` exclusion, and those users are not reviewed by anyone. ## Verification * **Scope persisted:** re-open the **Applications** tab and confirm the applications you chose and either the include list **or** the exclude list — never both. The tables behind them are `CERTIFICATION_APPLICATION` plus one of the two pairs listed above. * **Save accepted:** audit `MODIFY_CERTIFICATION` or `CREATE_CERTIFICATION` (the two constants are swapped when saving a certification); scope failures return `NO_ENTITLEMENT_SELECTED`. * **Coverage is what you intended:** run a preview and check **Review items — In scope** against your own count of memberships on the in-scope entitlements, and that the only `ROLE_EXCLUDED` / `GROUP_EXCLUDED` exclusions on the **Preview** tab are the ones you chose. ## When it goes wrong | Symptom | Cause | Fix | | -------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------- | | An expected role is absent from the entitlement picker | The role's `MANAGED_SYS_ID` does not match the selected application — the picker only offers entitlements of that managed system | Associate the role with the managed system, or certify it in a user campaign instead | | Save fails with `NO_ENTITLEMENT_SELECTED` | No application, role or group was selected — validation requires at least one of the three | Select an application; that alone satisfies the check in `ALL` and `EXCLUDED` modes | | An exclusion list disappeared after editing | Switching to *Select entitlements* clears both exclude tables, and switching back clears both include tables | The two modes are mutually exclusive; re-enter the list in the mode you intend to keep | | A new entitlement added this year was not reviewed | `SELECT` mode is an allow-list, so new entitlements fall out of scope silently | Use *Exclude entitlements* or *Use all entitlements* for recurring campaigns | | Preview excludes many users with `ENTITLEMENT_OWNER_NOT_FOUND` | Roles or groups in scope have no owner | Populate Owner on the entitlement, or add a fallback step with a concrete `USER` reviewer | | Preview excludes many users with `APPLICATION_OWNER_NOT_FOUND` | The application resource has no owner | Set the owner on the application resource | ## Related * [Plan and scope a campaign](/administration-guide/governance/certification/plan-and-scope-a-campaign.md) — preview, launch and the exclusion reasons * [Configure the review workflow](/administration-guide/governance/certification/configure-the-review-workflow.md) — owner and admin reviewer types * [Connectors and managed systems](/administration-guide/lifecycle/connectors-and-managed-systems.md) — what makes a role an entitlement of an application * [Review entitlements that live inside an application](/administration-guide/governance/certification/review-application-entitlements.md) — onboarding a non-AD application end to end, and the limits of nesting * [Shipped Groovy scripts](/administration-guide/reference/shipped-groovy-scripts.md) — the full script inventory *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/create-an-application-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.