> 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/sod/sod-policies-and-rule-sets/activate-an-sod-rule-set.md). # Activate an SoD rule set Turn a rule set into live SoD policies — read the activation preview as a mapping sheet, land it in Shadow, take the backlog count, then enforce and handle version drift. ## What this is, and when you need it Activation is what turns a catalogue of rule recipes into real `SOD_POLICY` rows that the engine evaluates. It is the point at which a rule set stops being content and starts having consequences: in `SHADOW` it produces a violation list, and after `Enforce` it starts refusing provisioning saves. It is also the point at which OpenIAM will happily create a hundred entitlements nobody asked for, if the preview says so and you activate anyway. Do this when you are adopting one of the ten shipped catalogues, or a set you imported yourself. The ladder and the severity override it re-derives are on [SoD policies and rule sets](/administration-guide/governance/sod/sod-policies-and-rule-sets.md); the SAP-specific readiness work that decides whether activation matches anything at all is on [SAP role and SoD analysis](/administration-guide/governance/sod/sap-sod-analysis.md). ## At a glance | | | | ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **You will end up with** | One `SOD_RULE_SET` at `STATUS = 'SHADOW'` or `'ENFORCED'`, with one active `SOD_POLICY` per confirmed rule and a counted violation backlog | | **Where** | **Access Control → Segregation of Duties → Rule Set Catalog** (`/webconsole/segregation-of-duties`) | | **You need first** | The managed system whose entitlements the rules should match; a decision on whether those entitlements are roles or groups; an approved mapping sheet | | **Takes** | 15 minutes to preview and land in Shadow. Weeks between Shadow and `Enforce`, spent remediating | | **Reversible** | **Partly.** Deactivating stops enforcement immediately, but entitlements activation created are **not** removed and deleting them is a separate deliberate cleanup | ## Before you begin Have a **mapping sheet** — a reviewed, line-by-line statement of which business function each rule reference represents and which real entitlement confers it, signed off by the application or process owner. Activate only when the preview matches it. If you cannot produce that sheet, you are not ready to activate; you are ready to start mapping. Read [Change configuration safely](/administration-guide/start/change-safely.md), and activate in **Shadow** the first time, always. An Enforced Critical rule refuses provisioning saves for the whole population from the moment it exists. ## Activate it {% stepper %} {% step %} ### Preview before you commit Open **Rule Set Catalog**, select one or more sets, and choose **Activate selected**. Pick the **Target managed system** — it scopes both entitlement matching and creation — and the concrete type generic `ENTITLEMENT` references become (`ROLE` by default). The dialog previews before it writes anything. It lists one row per rule with its verdict — **Will create policy** or **Already activated** — and, under each rule, the match outcome for every entitlement reference. The summary line reads `N policies will be created · N entitlements matched · N entitlements will be created`. Read the **will be created** count first. On a fresh managed system a 45-rule set can create well over a hundred entitlements that nothing provisions and nobody owns. Nothing is written until you confirm. {% endstep %} {% step %} ### Read the preview like a mapping sheet Each per-reference outcome asks something different of you. | Outcome | What it means | What to do | | ---------------- | ----------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Matched** | An existing entitlement of the right type matched by name, case-insensitively | Verify it is the *intended* object. **Never accept name similarity as proof**: a leftover `FK01` group somebody created for a test, an `FK01` role in a sandbox context, and the real transaction role all match the same string equally well, and the preview cannot tell them apart | | **Will create** | Activation will create the object | Confirm you want it to exist at all, and that its name and type are right. Every one of these is a new role or group in your access model, permanently | | **Ambiguous** | Several candidates matched and the first is used | Override it explicitly in the dialog. Leaving a guess in place means the policy evaluates against an entitlement chosen by iteration order | | **Needs manual** | An `ORGANIZATION` reference; organizations are never auto-created | Create the organization, then resync. Until then the reference is dropped and the policy is quietly narrower than the rule intended | Record the three summary numbers. If **will be created** dominates **matched**, stop: nothing in your access model matches this rule set, and activating produces orphan entitlements that will never detect anything. Use the per-entitlement overrides to point references at entitlements you already have, or run the preview again with the other create-as type — it is non-destructive, and the difference between the two counts is the answer. {% endstep %} {% step %} ### Activate in Shadow Choose **Shadow — all policies Soft (report only)**, then **Confirm activation**. Shadow creates the policies with severity forced `SOFT` and exceptions on, and sets `SOD_RULE_SET.STATUS = 'SHADOW'`, `ACTIVATED_AT` and `ACTIVATED_VERSION`. The result line reads `Created N policies, reactivated N, skipped N, created N entitlements`. Audit action: `ACTIVATE_SOD_RULE_SET`, described as `Activate SoD rule set in SHADOW mode`. To land a subset first, clear the per-rule checkboxes for the rules you are not ready for. Leaving them all selected activates every rule in the set. {% endstep %} {% step %} ### Run detection and read the backlog Use **Detect users** on the Violations tab, or **Run now** on Scheduled Detection, then work the Violations tab. See [SoD detection and violations](/administration-guide/governance/sod/sod-detection-and-violations.md) for the sweep and the digest, and [Work an SoD violation to closure](/administration-guide/governance/sod/sod-triage-remediation-and-evidence.md) for what to do with each hit. Do not skip this. Shadow's whole purpose is telling you the size of the existing conflict population before anything blocks. {% endstep %} {% step %} ### Fix the Critical conflicts, then enforce **Enforce** on the rule set's card (audit `ENFORCE_SOD_RULE_SET`) re-derives every policy's severity from its risk tag and sets `STATUS = 'ENFORCED'`; the screen confirms with `Rule set enforced`. Only a set in `SHADOW` may be enforced; anything else is rejected with `INVALID_ARGUMENTS`. From that moment, any provisioning operation that would leave a user holding a `SOD_RISK_CRITICAL` conflict fails with `SOD_POLICY_VIOLATION`. Every Critical conflict still outstanding becomes an operational block, so clear or mitigate them first — and note that enforcing sets `EXCEPTIONS_ALLOWED = N` on those policies, so there is no per-user escape hatch afterwards. {% endstep %} {% step %} ### Handle upgrades and drift **Compare...** on the card diffs the set field by field against another set or against **Activated policies (state at activation)**, and **Update available** appears on the card when a seeded set carries a newer `VERSION` than its `ACTIVATED_VERSION`. **Re-sync policies** shows which activated rules changed since their policies were created, then reapplies the current rules to those policies (audit `RESYNC_SOD_RULE_SET`, confirmed with `Policies re-synced`). **Activate more rules** is what turns rules a newer version added, or rules an earlier activation left unselected, into policies without touching the existing ones. Drift is detected in two directions by the two hashes on `SOD_POLICY`: `SOURCE_RULE_HASH` catches a rule edited after activation, `GENERATED_POLICY_HASH` catches someone editing the generated policy by hand on the Policies screen. The re-sync screen compares both and flags the second case per rule — `Edited directly — re-sync overwrites manual changes` — so a manual edit you want to keep must be reconciled before you re-sync, or it is overwritten. {% endstep %} {% endstepper %} ## Activate rules you imported yourself **Upload rule set** on the catalog opens **SoD Rule Set Upload**. Drop a file on the drop zone — **CSV**, **JSON** and **XML** are accepted, the format taken from the file extension, with a **10 MB** ceiling. The upload is a dry run first: the screen shows `N valid rules · N duplicates · N errors`, with a per-row error for anything it could not read, so you review the errors before anything is written. **Add to catalog** is what commits (audit `IMPORT_SOD_RULES`). Take the starting columns from **Download CSV template** — or the JSON or XML equivalent — rather than typing them. An imported set is `CUSTOM_UPLOAD`; one built in the UI is `CUSTOM_BUILT`. Both are editable. `OPENIAM_OTB` sets are read-only and the refusal happens on save, not merely by hiding the button, so a shipped set cannot be edited in place — clone the JSON, adjust it, and import it as your own. Then activate it with exactly the steps above. The schema, the column list and the field-by-field meaning are in [SoD rule and policy reference](/administration-guide/reference/sod-rules-and-rule-sets.md#the-rule-json-schema). ## Verification | What you did | Evidence | | -------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ | | Activated a set | `ACTIVATE_SOD_RULE_SET` with description `Activate SoD rule set in mode`; `SOD_RULE_SET.STATUS`, `ACTIVATED_AT`, `ACTIVATED_VERSION` | | Shadow really is non-blocking | Every generated policy has `SEVERITY = 'SOFT'` and `EXCEPTIONS_ALLOWED = 'Y'` | | Policies carry their rule provenance | `SELECT RULE_KEY, MODULE, RISK, POLICY_THRESHOLD FROM SOD_POLICY WHERE SOD_RULE_SET_ID = ?` returns one row per activated rule | | Activation matched instead of creating | The preview summary's *entitlements matched* dominates *will be created*, and per-reference statuses read `MATCHED` | | Detection ran and found the population | Documents in the `user-violated-sod-policy` index; `SOFT_SOD_POLICY_VIOLATION_DETECTION` audit entries | | Enforced a set | `ENFORCE_SOD_RULE_SET`; `STATUS = 'ENFORCED'` and `SEVERITY = 'HARD'` on exactly the `SOD_RISK_CRITICAL` policies | | Deactivated a set | `DEACTIVATE_SOD_RULE_SET`; `STATUS = 'INACTIVE'` | | Re-synced after an upgrade | `RESYNC_SOD_RULE_SET`; refreshed `SOURCE_RULE_HASH` and `GENERATED_POLICY_HASH` | | Imported rules | `IMPORT_SOD_RULES`, and the set appears with `SOURCE = 'CUSTOM_UPLOAD'` | ## When it goes wrong | Symptom | Cause | Fix | | ------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------- | | `Enforce` rejected | It is rejected with `INVALID_ARGUMENTS` unless `SOD_RULE_SET.STATUS` is `SHADOW` | Activate in Shadow first; you cannot go straight from `INACTIVE` to `ENFORCED` | | Severity reverted to `SOFT` after enforcing | Enforcing re-derives severity from the policy's risk tag, and only `SOD_RISK_CRITICAL` yields `HARD` | Change the rule's `riskLevel` to `CRITICAL`, or accept `SOFT` — editing `SEVERITY` by hand does not survive | | A Critical policy suddenly allows no exceptions | Enforcing sets `EXCEPTIONS_ALLOWED = N` whenever severity resolves to `HARD` | Attach a `SOD_MITIGATING_CONTROL`, or reclassify the rule | | Activation created a hundred entitlements | Every reference resolved *will create* against the chosen managed system | Deactivate, then re-activate with per-entitlement overrides pointing at existing entitlements. The created objects remain until you delete them | | Nothing matched although the names are right | Only candidates in the target managed system are considered; yours have no managed system, or a different one | Attach the entitlements to that managed system, or pick the right system in the dialog | | Nothing matched and your entitlements are groups | A generic `ENTITLEMENT` reference resolves against **one** type only — the create-as type, default `ROLE` | Set the type to `GROUP` and re-run the preview to confirm before committing | | An organization reference was dropped | *Needs manual* — organizations are never auto-created | Create the organization, then resync | | The wrong entitlement was matched | *Ambiguous*: several matched by name and the first was used | Rename to disambiguate, or override the reference in the activation dialog | | A shipped set will not save | A set whose `SOURCE` is `OPENIAM_OTB` is read-only and OpenIAM refuses the save | Export the JSON, edit it, import it as `CUSTOM_UPLOAD` | | Resync overwrote a policy someone had edited | `GENERATED_POLICY_HASH` no longer matched the live policy, and resync reapplies the rule | Reconcile manual edits before resyncing, or keep hand-built policies out of rule sets | | A field you set on an imported rule disappeared | Import silently discards any property it does not recognise, with no rejected-field list | Export what you imported and diff it against your source file | | The card reads **Partial** although you activated everything | Some rules were skipped as **Incomplete**, an earlier activation left rules unselected, or a newer version added rules | Use **Activate more rules** | | Provisioning suddenly fails across the population | A set was enforced with Critical conflicts outstanding | Look for `HARD_SOD_POLICY_VIOLATION_DETECTION` entries; deactivate the set or clear `ACTIVE` on the offending policies while you remediate | ## Roll it back **Deactivate** on the rule set's card — it confirms with `Rule set deactivated` — sets `STATUS = 'INACTIVE'` and leaves its generated policies inactive, which stops enforcement immediately without deleting anything. **Entitlements created at activation are not removed** — they remain as roles or groups with no memberships, and deleting them is a separate, deliberate cleanup. To unblock a single policy without touching the set, clear `ACTIVE` on that `SOD_POLICY` row, or set `SEVERITY = 'SOFT'` knowing the next `Enforce` will undo it. ## Related * [SoD policies and rule sets](/administration-guide/governance/sod/sod-policies-and-rule-sets.md) — the ladder, the severity override and the two enforcement points * [SAP role and SoD analysis](/administration-guide/governance/sod/sap-sod-analysis.md) — the readiness work that decides whether the shipped content matches anything * [SoD detection and violations](/administration-guide/governance/sod/sod-detection-and-violations.md) — the sweep and the digest that turn Shadow into a number * [SoD rule and policy reference](/administration-guide/reference/sod-rules-and-rule-sets.md) — the schema, the ten catalogues, and what activation creates *Applies to OpenIAM 2026.8.1. Last reviewed 7 August 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/sod/sod-policies-and-rule-sets/activate-an-sod-rule-set.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.