> 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/identities/delegated-administration.md). # Scope a delegated administrator Scope an administrator to a population with delegation filters, and understand the three other mechanisms — organization scope, subordinate checks and association types — that decide what they can rea ## What this is, and when you need it Delegated administration narrows what one administrator can see and touch — a regional help desk that handles only EMEA, a manager who administers only their own reports. OpenIAM has no "tenant administrator" object; you assemble the scope from up to four independent mechanisms, of which **delegation filters** are the primary one. Getting this wrong has a population-sized consequence in the safe direction (somebody cannot do their job) and in the unsafe one (somebody can reset anyone's password). One shipped default makes the second case likely, and it is the first step below. ## At a glance | | | | ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------- | | **You will end up with** | An administrator whose searches and operations reach only their population | | **Where** | `/webconsole/userDelegation?id=` | | **You need first** | The roles, groups and organizations you intend to put in the filter must be visible to **you** — the save is scoped by your own reach | | **Takes** | 15–30 minutes including the two tests at the end | | **Reversible** | Yes — record the previous filter values before you change them and write them back | ## Scope the administrator The worked example: give a help desk lead administrative reach over one division only, and the ability to reset their own reports' passwords and nobody else's. {% stepper %} {% step %} ### Close the direct-report password loophole first | Property | Shipped default | Label | | ----------------------------------------------- | --------------- | ---------------------------------------- | | `org.openiam.ui.enforce.subordinate.check.flag` | `false` | Enforce subordinate check for operations | {% hint style="danger" %} Read that default carefully. A requester who lacks `USER_RESET_PASSWORD` but holds `RESET_PASSWORD_DIRECT_REPORT` is authorized to reset a password — and the subordinate list is only consulted when this property is `true`. So on shipped configuration, **"reset the password of a direct report" is in practice "reset the password of any user"**. If you grant `RESET_PASSWORD_DIRECT_REPORT` to line managers — which is the obvious reason to grant it — set this property to `true` **before** you grant it, not after. {% endhint %} {% endstep %} {% step %} ### Confirm the organization type IDs match your hierarchy Organization, division and department are the same kind of object, separated by organization type. Three properties name which type is which, at **Administration → System Configuration**, category `Organization`: | Property | Shipped default | | ---------------------------------- | --------------- | | `org.openiam.organization.type.id` | `ORGANIZATION` | | `org.openiam.division.type.id` | `DIVISION` | | `org.openiam.department.type.id` | `DEPARTMENT` | If your hierarchy uses different type IDs, the organization, division and department filters will not populate correctly until these properties match. Either correct the properties, or use the organization filter for everything. {% endstep %} {% step %} ### Set the delegation filter Open `/webconsole/userDelegation?id=` — the screen is headed **Delegation Filter for User**. Pick the division the lead is to administer. The screen offers five lists — organization, division, department, group and role — and two checkboxes: | Checkbox | Set it when | | -------------------------------- | ---------------------------------------------------------------------------------------------------------- | | **Use Organization Inheritance** | The lead should also reach the organizations below the ones you picked, rather than only the exact matches | | **Direct Reports Only** | The lead should reach only their own management reporting line, whatever the lists say | For the worked example: put the division in the division list, tick **Use Organization Inheritance**, and leave **Direct Reports Only** clear — the lead administers a division, not a reporting line. Save. The screen confirms with "Delegation Filter for user was saved successfully". {% endstep %} {% step %} ### Read the filter back off the user record A delegation filter is not stored in a delegation table. It is a set of **user attributes on the delegated administrator's own record**: | Attribute | Holds | | --------------------- | ------------------------------------------------------------ | | `DLG_FLT_ORG` | Comma-separated organization IDs | | `DLG_FLT_DIV` | Comma-separated division IDs | | `DLG_FLT_DEPT` | Comma-separated department IDs | | `DLG_FLT_ROLE` | Comma-separated role IDs | | `DLG_FLT_GRP` | Comma-separated group IDs | | `DLG_FLT_APP` | Comma-separated application IDs | | `DLG_FLT_MNG_RPT` | `true` / `false` — restrict to the management reporting line | | `DLG_FLT_USE_ORG_INH` | `true` / `false` — follow organization inheritance | Those eight are the entire vocabulary, and the separator is a literal comma. Open the lead's record and confirm `DLG_FLT_DIV` holds the division ID and `DLG_FLT_USE_ORG_INH` holds `true` — the attribute readback is how you tell a filter that saved from one that silently saved empty. {% endstep %} {% step %} ### Test one case that must succeed and one that must fail Sign in as the lead. Search for a user inside the division — must be found. Search for a user outside it — must not be. Then attempt a password reset on a user outside their reporting line: with `org.openiam.ui.enforce.subordinate.check.flag` now `true`, it must be refused. A scope you have not tested in both directions is a scope you have not set. {% endstep %} {% endstepper %} ## Verification | What you did | Evidence | | --------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- | | Set a delegation filter | The success message "Delegation Filter for user was saved successfully", then the `DLG_FLT_*` attributes on the delegated administrator's own record | | Enforced subordinate checks | A holder of `RESET_PASSWORD_DIRECT_REPORT` is refused on a non-subordinate | | Restricted a population | The lead finds a user inside the scope and does not find one outside it | ## When it goes wrong | Symptom | Cause | Fix | | ------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------- | | The save fails with "Unable to save Delegation Filter for user" | The target user, or the filter content, is outside **your own** scope. You cannot delegate scope you do not yourself hold | Grant yourself the roles, groups or organizations first, then save | | The filter saved but the scope did not change | The organization type IDs do not match your hierarchy | Correct the three type properties, or use `DLG_FLT_ORG` | | Clearing a filter did not widen the scope | Saving an empty list writes an **empty value**, it does not remove the attribute | Clear the attribute value on the user record directly | | Directory lookup ignores the delegation filter | `org.openiam.ui.selfservice.directory.lookup.skip.delegation.filter` ships `true`, so a directory-lookup search bypasses the filter | Deliberate — see below. Set it `false` if your directory must respect scope | | A direct-report password reset succeeded on somebody who is not a report | `org.openiam.ui.enforce.subordinate.check.flag` ships `false` | Set it `true` | | **Restrict search to organization scope** appears to do nothing | It has no effect in the Webconsole at all | Expected — see below | | A scoped SelfService user sees nobody at all | Organization scoping is on and that requester has no organization affiliation | Give them an affiliation. Empty-rather-than-unfiltered is the safe direction, but it looks like a broken screen | ## Roll it back **Delegation filters** — reversible. Record the previous `DLG_FLT_*` attribute values before you change them and write them back. Remember that saving an empty list leaves an empty attribute behind rather than removing it. **`org.openiam.ui.enforce.subordinate.check.flag`, `org.openiam.selfservice.organization.search.enabled`, `org.openiam.ui.selfservice.directory.lookup.skip.delegation.filter`** — reversible property changes. ## The other three mechanisms Delegation filters are one of four things that decide what an administrator can reach. You will normally use more than one. ### Organization-scoped search does much less than its label suggests | Property | Shipped default | Webconsole label | | ----------------------------------------------------- | --------------- | ----------------------------------------- | | `org.openiam.selfservice.organization.search.enabled` | `false` | **Restrict search to organization scope** | OpenIAM limits a search to organization scope only when **all three** of these hold: the property is on, the requester is not a member of the super security admin role, and the request came in under `/selfservice`. **Turning it on has no effect whatsoever on the Webconsole** — if you need administrators scoped, use delegation filters. Where it does apply it applies broadly: a scoped SelfService user's managed system, role, group, resource and organization searches are all narrowed to their organizations, and all return empty rather than unfiltered when the requester has no organizations at all. It also hides the Organization criterion from the search form exactly when scoping is in force — see [User search configuration](/administration-guide/reference/user-search-configuration.md). ### The directory deliberately ignores the filter | Property | Shipped default | Effect | | -------------------------------------------------------------------- | --------------- | ---------------------------------------------------------------------------------------------------------------------------- | | `org.openiam.ui.selfservice.directory.lookup.skip.delegation.filter` | `true` | When `true` and the search is flagged as a directory lookup, no requester is passed, so the delegation filter is not applied | That is a deliberate shipped decision: the corporate directory is meant to be visible to everyone even where administrative scope is not. If your directory must respect delegation, set it to `false`. ### Subordinate checks Some operations accept "this person reports to me" as authorization in place of a global grant. The subordinate list is walked recursively and **includes the starting user**, so a requester always counts as their own subordinate for these checks. **Enable** and **Disable** use it unconditionally: a requester lacking `USER_EDIT_INFO` **and** `ENABLE_USER`/`DISABLE_USER` is still allowed when the target is a subordinate. Password reset gates it behind `org.openiam.ui.enforce.subordinate.check.flag`, above. ### Ownership and administration associations Administrative responsibility over one specific object is expressed with association types: `OWNER`, `ADMIN`, `APPLICATION_OWNER`, `APPLICATION_ADMIN`, `ENTITLEMENT_OWNER`, `ENTITLEMENT_ADMIN` and `SERVICE_ACCOUNT_OWNER`. These are per-object, which makes them the right tool for "this team administers this application" and the wrong tool for "this administrator handles this region". {% hint style="info" %} Older documentation describes setting an **admin resource** on a role, group or organization. That schema no longer exists: the `ADMIN_RESOURCE_ID` columns were added to `RES`, `ROLE`, `GRP` and `COMPANY` in 3.1.0.0 and all four were dropped again in 4.0.0.0. The `ADMIN_RESOURCE` row in `RESOURCE_TYPE` survives, but there is no column left to point at it — `DESCRIBE ROLE` will confirm it on your own build. Use delegation filters and association types instead. {% endhint %} ## Related * [Change many users at once](/administration-guide/identities/bulk-operations.md) — the other population-sized operation on this section * [Find a user](/administration-guide/identities/find-a-user.md) — what a scoped administrator's search actually returns * [Change configuration safely](/administration-guide/start/change-safely.md) — the reviewed-change list these settings belong on *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/identities/delegated-administration.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.