> 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/access/manage-roles-and-groups/role-and-group-reference.md). # Role and group field reference Every field on the shipped role and group forms, which template flags the forms actually honour, and the 23-column entitlement CSV header. ## What this covers Three exhaustive lists that the task pages deliberately do not repeat: the fields the shipped **Default Role Template** and **Default Group Template** render, the fields the role form carries outside any template, and the column contract of the entitlement CSV import. Nothing here is a procedure. To create a role, go to [Create a role](/administration-guide/access/create-a-role.md); to load a catalog from file, go to [Role engineering and maintenance](/administration-guide/access/role-engineering.md). Compare every table below against your own deployment at **Administration → Page Template**. The role form is rendered from `DEFAULT_RL_TEMPLATE` (template type `ROLE_TEMPLATE`) and the group form from `DEFAULT_GRP_TEMPLATE` (`GROUP_TEMPLATE`); an upgraded system can differ from a fresh one, and a deleted template row removes the field. ## The shipped Default Role Template `DEFAULT_RL_TEMPLATE` ships twelve `UI_FIELD_TEMPLATE_XREF` rows. Eleven have shipped since 4.1.0.0; the twelfth, `ROLE_PARTICIPATE_CERTIFICATION`, was added as of 4.2.0.0. The **Label** column is the English `LANGUAGE_MAPPING` value, which is what the form actually renders — OpenIAM prefers the language mapping for the reader's locale and falls back to `UI_TEMPLATE_FIELDS.NAME` when there is no mapping, so a field whose label looks like an internal identifier is a field missing its mapping. | `UI_FIELD_ID` | Label | `IS_REQUIRED` | `IS_EDITABLE` | Order | On the shipped form? | | -------------------------------- | ----------------------------------- | ------------- | ------------- | ----- | --------------------------- | | `ROLE_NAME` | Role Name | `Y` | `Y` | 1 | Yes | | `ROLE_DESCRIPTION` | Role Description | `N` | `Y` | 2 | Yes | | `ROLE_MANAGED_SYS` | Role Managed System | `N` | `Y` | 3 | Yes | | `ROLE_RISK` | Role Risk | `N` | `Y` | 4 | Yes | | `ROLE_STATUS` | Role Status | `N` | `Y` | 5 | Yes | | `ROLE_MAX_USERS` | Max. User Number | `N` | `Y` | 6 | Yes | | `ROLE_MEMBERSHIP_DURATION` | Default Membership Duration | `N` | `Y` | 7 | Yes | | `ROLE_PARENT` | Role Parent | `N` | `Y` | 8 | Yes, **on create only** | | `ROLE_OWNER` | Role Owner | `N` | **`N`** | 9 | Yes, but `editable` ignored | | `ROLE_ADMIN` | Role Admin | `N` | **`N`** | 10 | Yes, template row not read | | `ROLE_ADMIN_RESOURCE` | Protected by | `N` | **`N`** | 11 | **No** | | `ROLE_PARTICIPATE_CERTIFICATION` | Participate in Access Certification | `Y` | `Y` | 10 | **No** | Only `ROLE_NAME` ships required, so the form will save with a name alone. ### The three non-editable rows, and what really happens The owner, admin and admin-resource rows ship `IS_EDITABLE='N'`. It would be reasonable to conclude that you cannot set a role's business owner until you edit the template. The shipped form does not behave that way, and the difference matters: * For the eight fields **Role Name**, **Role Description**, **Role Managed System**, **Role Risk**, **Role Status**, **Max. User Number**, **Default Membership Duration** and **Role Parent**, `IS_EDITABLE='N'` genuinely locks the input. * **Role Owner** honours only `IS_REQUIRED` from the template. The picker is drawn unconditionally and never consults `IS_EDITABLE`. * **Role Admin** is the same, and does not consult the template at all. * The **Protected by** and **Participate in Access Certification** rows drive no control on the form, whatever their flags say. So in practice **Role Owner and Role Admin are editable on the shipped form despite the template saying otherwise**, and the "Protected by" and "Participate in Access Certification" rows are inert. Confirm this on your own release in two minutes, and do it before you rely on either behaviour: open `/webconsole/editRole?roleTypeId=ACCESS_ROLE`, and try to use the **Role Owner** picker. If it opens and lets you select a user, `IS_EDITABLE='N'` is not being enforced for that field on your release. Then look for a **Protected by** control; on the shipped form there is none. {% hint style="warning" %} This is a product defect, not a configuration choice, and it cuts both ways. Do not rely on `IS_EDITABLE='N'` on `ROLE_OWNER` or `ROLE_ADMIN` as a control — it is not enforced, so an administrator who can reach the role edit screen at all can reassign its owner. And do not conclude the product cannot record a role owner — it can, from the picker. Re-run the two-minute check above after any upgrade: the template row and the form are maintained independently, so either could change without the other. {% endhint %} ### Certification participation `ROLE_PARTICIPATE_CERTIFICATION` ships `IS_REQUIRED='Y'`, `IS_EDITABLE='Y'`, display order `10` — which collides with `ROLE_ADMIN`'s order `10`. Its group twin, `GROUP_PARTICIPATE_CERTIFICATION` on `DEFAULT_GRP_TEMPLATE`, ships identically. Neither drives a control on its form, and neither is a field on the role or group itself; the flag that certification actually reads is `RES.PARTICIPANT_CERTIFICATION` on the resource. Scope role review from the campaign instead — see [Plan and scope a campaign](/administration-guide/governance/certification/plan-and-scope-a-campaign.md). Because the row ships required and renders nothing, a role save can fail with "fill required fields" while every visible field is populated. Set that xref's `IS_REQUIRED` to `N`, or delete the row. ## Fields on the role form that are not in the template These four appear on the form outside any template guard, so they are present regardless of what the template contains. Deleting a template row will not remove them: | Label | Field | Label key | Notes | | ---------------------------------- | ------------------- | --------------------------------------------- | --------------------------------------------------------------------------------------------------------------- | | Password Policy | `policyId` | `openiam.ui.password.policy` | Marked required on the form itself, not by the template, so you cannot make it optional from **Page templates** | | Virtual tenant role | `virtualTenantRole` | `org.openiam.role.for.virtual.tenant.enabled` | Accepts `SUPER_SEC_ADMIN`, `ORGANIZATION_ADMIN`, `END_USER` | | Provision all users with this role | `assignToAll` | `openiam.ui.idm.prov.role.field.assignToAll` | Ships `false` | | Is Visible | `visible` | `openiam.ui.common.is.visible` | Ships checked on a new role | The owner and admin pickers label themselves from `openiam.ui.role.owner` (**Role Owner**) and `openiam.ui.role.admin` (**Role Administrator**) — note the second differs from the template row's **Role Admin**. {% hint style="danger" %} **Provision all users with this role** grants this role to the entire user population. Combined with any provisioning the role's resources drive, it is the widest single checkbox on the page. Never set it on a role that carries a managed-system entitlement until you have measured the population — count the active users first, and expect one provisioning operation per user per managed system. {% endhint %} ### Virtual tenant role is a visibility filter, not a job title **Virtual tenant role** is the switch behind OpenIAM's virtual-tenant scoping, not a description of the role's purpose. `SUPER_SEC_ADMIN` sees everything; `ORGANIZATION_ADMIN` and `END_USER` can retrieve only entitlements whose organization matches the requester's. Set it only if you are implementing that scoping model, and prove it with a test account in one organization: search for a role belonging to another organization and confirm it does not come back. Tenant scope changes what every administrator can see — see [Change configuration safely](/administration-guide/start/change-safely.md#changes-with-a-wide-blast-radius). ## The role field on neither the form nor the template A role carries a persisted exclude-from-authorization flag in the column `ROLE.EXCLUDE_FROM_AUTH`, which ships `'N'` as of 4.2.1.12 and has no control on the shipped form. When it is `'Y'` the role is left out of authorization evaluation, so the role can carry membership and provisioning meaning without contributing to effective access. **The Webconsole offers no path to this flag** — no control on the form, and no page-template field that renders it. A role with it set looks fully populated and grants nothing, and no screen will tell you why. {% hint style="warning" %} **Break-glass read.** Reading the column is the only way to see the flag. The read is safe; the write is not, so do not make one. {% code overflow="wrap" %} ```sql SELECT ROLE_NAME, EXCLUDE_FROM_AUTH FROM ROLE WHERE ROLE_ID = ''; ``` {% endcode %} OpenIAM sets this column when the role is created and does not change it afterwards, so no role save will flip it and an `UPDATE` of your own leaves the authorization graph disagreeing with the row until the graph is rebuilt — see [Rebuild the authorization graph](/administration-guide/operations/rebuild-the-authorization-graph.md). If you need a role excluded from authorization, ask OpenIAM support to set it, and record it in your own change log; nothing on any screen will remind you later. {% endhint %} If a role's members demonstrably lack its access and `/webconsole/authorizationDebug` shows the membership but not the access, read that column before you have the graph rebuilt. ## The shipped Default Group Template `DEFAULT_GRP_TEMPLATE` carries sixteen fields after all migrations. Most mirror the role template row for row. The ones that differ: | `UI_FIELD_ID` | Label | Notes | | --------------------------------- | ----------------------------------- | ----------------------------------------------------------------- | | `GROUP_CLASSIFICATION` | Classification | A `GROUP_TYPE` metadata type: `AD_GROUP` or `GENERAL_GROUP` ship | | `GROUP_AD_GROUP_TYPE` | AD Group Type | Shown for AD groups only | | `GROUP_AD_SCOPE` | AD Group Scope | Shown for AD groups only | | `GROUP_ORGANIZATION` | Organizations | Ships `IS_EDITABLE='N'` | | `GROUP_PARTICIPATE_CERTIFICATION` | Participate in Access Certification | Ships `IS_REQUIRED='Y'`, and like its role twin drives no control | `GROUP_OWNER`, `GROUP_ADMIN`, `GROUP_ADMIN_RESOURCE` and `GROUP_ORGANIZATION` all ship `IS_EDITABLE='N'`, the same pattern as the role template — with the same caveat, above, about which of those flags the form actually honours. There is also a shipped custom field, `GRP_DN_FLD_FILED` labelled **DistinguishedName**, scoped to metadata type `AD_GROUP`. Unlike the built-in template fields it renders through the shared template widget, so its `IS_EDITABLE` flag *is* honoured — set it read-only and the field really is read-only. ## What you can and cannot change from Page templates Adding a field means adding a `UI_FIELD_TEMPLATE_XREF` row — but a template row only has an effect if the edit form already has a control bound to that `UI_FIELD_ID`. Of the twelve shipped role rows, nine drive a control. Inventing a thirteenth `UI_TEMPLATE_FIELDS` row will add the row and no control, and nothing will tell you: the template screen accepts it and the role form is unchanged. What you *can* change at **Administration → Page Template → Default Role Template**: * **Make a field required.** Set `IS_REQUIRED='Y'`. It is enforced in the browser and again on the save request, so it holds against an integration as well as against the form. This is the right way to force every role to carry a description or a risk rating. Confirm it by saving a role with the field blank — the save must fail. * **Make one of the eight honoured fields read-only.** Set `IS_EDITABLE='N'` on `ROLE_NAME`, `ROLE_DESCRIPTION`, `ROLE_MANAGED_SYS`, `ROLE_RISK`, `ROLE_STATUS`, `ROLE_MAX_USERS`, `ROLE_MEMBERSHIP_DURATION` or `ROLE_PARENT`. * **Reorder or relabel.** `DISPLAY_ORDER` on the xref sets the order. The label comes from the `LANGUAGE_MAPPING` row whose `REFERENCE_ID` is the xref ID — `RL_NAME`, `RL_DESCRIPTION`, `RL_MANAGED_SYS`, `RL_RISK`, `RL_STATUS`, `RL_MAX_USERS`, `RL_MEMBERSHIP_DURATION`, `RL_PARENT`, `RL_OWNER`, `RL_ADMIN`, `RL_ADMIN_RES`, `RL_PARTICIPATE_CERTIFICATION` — so relabelling is a language mapping change, not a template change. * **Remove a field.** Delete the xref row and the field vanishes from the form: every one of the nine honoured controls is drawn only when its template row is present. For a genuinely new attribute, use a **role attribute** (`ROLE_ATTRIBUTE`) rather than a template field, or add a `METADATA_ELEMENT` custom field to the template. Custom fields render through the shared template widget, which *does* honour `IS_EDITABLE` — so unlike the built-in owner and admin pickers, a read-only custom field really is read-only. See [Build a page template](/administration-guide/identities/page-templates-and-custom-fields.md). ## The entitlement CSV columns The shipped synchronization configuration **`ent_csv_ex2`** loads roles and groups from a file with twenty-three columns, in the order its header declares them. Its group twin is `grp_csv_ex1`; the applications equivalent is `application_csv_ex3`, whose header includes `PARTICIPATE_IN_ACCESSCERTIFICATION`, `CATEGORY_NAME` and `PERMISSIONS_LIST`. The header itself, and how to run the load, are in [Role engineering and maintenance](/administration-guide/access/role-engineering.md#build-load-the-catalog-do-not-hand-type-it). Where OpenIAM's own documentation of the entitlement import does not describe a column, this table says so rather than guessing — the transformation script selected on the configuration is the only authority on that column's semantics. | # | Column | What it carries | | -- | ------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 1 | `MANAGED_SYSTEM_NAME` | The managed system name — the application this entitlement belongs to. Populating it is also a design signal: a role with a managed system is a target permission | | 2 | `GROUP_TYPE` | Not described. The group counterpart of the next column, used when the row loads a group through `grp_csv_ex1` | | 3 | `ROLE_TYPE` | Not described per column. This is the role **Type** field — the only `ROLE_TYPE` metadata there is, `ACCESS_ROLE` or `PROVISION_ROLE` | | 4 | `ENTITLEMENT_NAME` | Not described per column. The name of the role or group the row creates. It is the value everything else resolves by, so make it unique and stable | | 5 | `IS_ACTIVE` | `Y` — the configuration is available for use. `N` — disabled, and no tasks will be processed for it | | 6 | `ENTITLEMENT_OWNER_TYPE` | The type of owner: **User** or **Group** | | 7 | `ENTITLEMENT_OWNER` | The name of the owner. This is the field certification reviewer resolution and request approval depend on | | 8 | `ENTITLEMENT_ADMIN_TYPE` | The type of administrator: **User** or **Group** | | 9 | `ENTITLEMENT_ADMIN` | The name of the administrator | | 10 | `APPROVER1_TYPE` | The type of the first approver: supervisor, application owner, application admin, entitlement owner, or a specific user or group | | 11 | `APPROVER1` | The name of the first approver — a user name or a group name | | 12 | `APPROVER2_TYPE` | The type of the second approver, from the same set | | 13 | `APPROVER2` | The name of the second approver — a user name or a group name | | 14 | `APPROVER3_TYPE` | The type of the third approver, from the same set | | 15 | `APPROVER3` | The name of the third approver — a user name or a group name | | 16 | `AD_GROUPS` | Not described. Present in the verified header; read the transformation script before you populate it | | 17 | `ATTRIBUTE_NAME1` | Not described per column. The name of the first role attribute | | 18 | `ATTRIBUTE_VALUE1` | Not described per column. Its value | | 19 | `ATTRIBUTE_NAME2` | Not described per column. The second attribute's name | | 20 | `ATTRIBUTE_VALUE2` | Not described per column. Its value | | 21 | `ATTRIBUTE_NAME3` | Not described per column. The third attribute's name | | 22 | `ATTRIBUTE_VALUE3` | Not described per column. Its value | | 23 | `MAX_MEMBERSHIP_DURATION` | Not described per column. The maximum membership duration — the default expiry applied to new memberships, and the thing `CHANGE_MEMBERSHIP_DURATION` retrofits | {% hint style="warning" %} **Do not take a column list from the older *****Importing roles***** page.** Its table describes `DESCRIPTION`, `IS_MANUAL`, `IS_VISIBLE`, `PARTICIPATE_IN_ACCESS_CERTIFICATION`, `CONNECTOR_NAME`, `URL`, `PORT`, `CATEGORY_NAME` and `PERMISSIONS_LIST`, and it names the owner and admin columns `APPLICATION_OWNER` and `APPLICATION_ADMIN`. Those belong to the **applications** format, `application_csv_ex3`, not to `ent_csv_ex2` — and the entitlement format calls them `ENTITLEMENT_OWNER` and `ENTITLEMENT_ADMIN`. A file built from that page will not load through the entitlement configuration. If you need a column this header does not have, the transformation script has to be extended to read it: copy the shipped script into your own path in **Groovy Manager**, change it there, and select your copy in the synchronization's **Transformation rule**. {% endhint %} ## Related * [Create a role](/administration-guide/access/create-a-role.md) — the procedure these fields belong to * [Manage roles and groups](/administration-guide/access/manage-roles-and-groups.md) — membership, nesting and effective dates * [Role engineering and maintenance](/administration-guide/access/role-engineering.md) — loading a catalog from the CSV above * [Enumerated values](/administration-guide/reference/enums.md) — risk levels, statuses, bulk operations *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/access/manage-roles-and-groups/role-and-group-reference.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.