Resources

Resources are one of the core objects in the Omada Identity data model. A resource represents an entitlement, role, permission, or account in a connected target system. Resources are organized by resource types and resource folders, and are associated with systems.

This page provides reference information for resource types, resource folders, resource properties, and the AI Description Optimizer (technical preview feature) for resources.

note

For step-by-step instructions on configuring resources during system onboarding, see Resources (Import and Onboarding).

Resource types

Resource types define the categories and behavior of resources. Each resource is associated with exactly one resource type.

Resource type settings

Setting	Description
Name	Type a unique name for the new resource.
Resource category	Select a relevant resource category to associate with the new resource type.
Allow attributes	Enable this setting to allow assignments for resources of this type to have attributes.
Attribute set	Choose an attribute set of attributes that are allowed on assignments for resources of this type. The attributes are displayed in the access request when a user picks a resource of the resource type. You can modify the specific display behavior on the attribute type object. The assignments calculated by RoPE hold values for the attributes. By default, the attribute values are considered relevant for provisioning. If you need to, you can change this by using the Provisioning attribute set property.
Business key	Add a business key for the created resource type.
Provisioning attribute set	Choose an attribute set to use for provisioning. Attributes that have fulfillment relevance. If you do not specify a provisioning attribute set, then all assignment attributes are considered provisioning relevant. The attributes in the provisioning attribute set must be a subset of the attributes in the general attribute set.
Reconcile on attribute level	Enable this setting if discrepancies on provisioning attributes in the ODW should result in provisioning updates.
Reconciliation attributes map	Type a mapping string to use for reconciliation. The mapping string is used by RoPE when loading account- or permission assignment attributes from Omada Identity Data Warehouse. The mapping string maps ES/RoPE attribute names to Data Warehouse attribute names. If a resource type specifies an attribute string, then RoPE only looks for the mapped attributes in Omada Identity Data Warehouse. If a resource type does not specify anything, RoPE assumes that all provisioning attributes are present in Omada Identity Data Warehouse (with the same names as in the Enterprise server). The mapping string has the following format: [Attribute system name in ES/RoPE]=[Attribute name in Data Warehouse];... The mapping string must not contain duplicate attribute names. Neither ES/RoPE attribute names nor Data Warehouse attribute names. Note that the mapping string is not case-sensitive. Example of mapping string: FirstName=fn;LastName=givenname
Exclusively managed	Enable this setting if calculated assignments for resources of this type should be deprovisioned if they do not have a 'desired state' reason. Omada recommends that you enable this setting, except during initial implementation or onboarding of a system.
Post-validity (days)	Calculated assignments for resources of this type are kept for this number of days after the validity period ends. A "post-valid" assignment is always marked as disabled by Omada Identity, which leads to inactivation or deletion in the target system. For account resources, it can be an especially good idea to use post-validity to delay the deletion of an account in the target system when an employee is offboarded.
Always provision changes	Should every single change of provisioning attributes cause provisioning updates? If enabled, settings Reconcile on attribute level and Reconciliation attributes map are ignored.
MIM MA CS resource object type	Expose resources in the MIM MA connector space as objects of this type. Only relevant for systems configured for using MIM as a fulfillment mechanism.
MIM MA CS assignment object type	Expose calculated account/permission resource assignments in the MIM MA connector space as objects of this type. Only relevant for systems configured for using MIM as a fulfillment mechanism.
Make members/ membership information available in the sync engine	If the resource category is Permission, enable showing the accounts that are members of the resource in the MIM MA connector space. If the resource category is Account, enable showing the resources that the account is a member of in the MIM MA connector space.
Allow child resources	Enable this setting to allow resources that do not belong to the Role resource to be able to specify child resources. For the Role resource, this checkbox is selected by default and is mandatory.
Allow delegation	Enable this setting to allow identities with this resource type to delegate their access to another identity for a limited period of time, for example, in case of vacation or a leave of absence.
Prevent self-service	Select Yes if you do not want this resource type to be available for self-service access requests.
Policy and risk checks	Select the policy and risk checks that should be executed for the resource type. If a check is not selectable, it is used for all resources.

Renaming resource types

To rename the resource types provided by default in the System onboarding process, create a new resource type based on the default resource type, and make changes to the copy.

Resource type names are used in the system configuration. Changing one of the default resource types requires changing the name in several places.

To update the resource type name, perform the following steps:

Prerequisites

1. Stop the Role and Policy Engine (RoPE).

2. Stop the Enterprise Server (ES) timer service.

3. Update the ES configuration:

   1. Update the resource type name in the list of resource types.

   2. Open the list of systems (a warning will be displayed).

   3. For each system where the resource type is used:

      1. Open the ellipsis menu on the right and select Edit (advanced).
      2. In the Provisioning service configuration field, rename the resource type accordingly.
      3. Click OK to close the system dialog.

   4. Go to Task mappings and validate them.

      note

      The name of the resource type in the data model can be updated, but it is not strictly necessary. If required, perform this step before editing the task mappings.

      Business key

      It is not recommended to update the Business key value of the resource type even if it matches the old resource type name.

   5. Commit the OPS settings.

4. Update the RoPE EngineConfiguration.config:

   • Update the AttributeValueResolver extension:

     • Update Resource driven attributes (#ASSIGNMENTS_PER_RESOURCETYPE):
       • The name element contains the attribute name, for example, MBOXSIZE. It can be prepended with a resource type name, for example, AD Account:MBOXSIZE.
       • The first element after #ASSIGNMENTS_PER_RESOURCETYPE is a resource type name, it must be updated accordingly, for example, /#ASSIGNMENTS_PER_RESOURCETYPE/Mailbox size:[MBOXSIZE].
     • Update the MapAttributesFromActualDataExtension extension:
       • The ExtraInfo configuration element contains the display name of resource types, unless prepended with UID:. It must be updated accordingly.

5. Perform a service restart:

   1. Start the timer service(s) and wait for 2 minutes for the resource type to be synchronized.
   2. Start the RoPE service(s).

warning

The Resource type names support the characters from the [^A-Za-z0-9_-!@#$%^&*()] range, including space.

Resource folders

Resource folders provide a way to organize resources and define ownership, approval, and provisioner settings at the folder level.

Resource folder settings

Setting	Description
Name	Type a unique name for the resource folder.
FolderID	Type a unique FolderID for the resource folder. You can only use capital letters.
Effective owner	Automatically populated by RoPE.
Manual Owners	Select an owner of the resource folder and its resources. This is an optional setting.
Approval	Select the level of the approval (for example, System Owner or Context Owner level). You can select one or more levels.
Provisioner	Select an identity from the list to act as the provisioner. Only one identity can be assigned per resource folder.
Account types	Select one or more account types for which the resources in the folder are relevant. This setting may be overridden on the individual resource.
Classifications	Select a classification tag for the created resource folder.
Policy and risk checks	Select the policy and risk checks to execute for the resource type. Checks that are not selectable apply to all resources.

Resource settings

Each resource represents a specific entitlement, role, permission, or account within a system.

Resource properties

Setting	Description
ResourceID	Type a unique resource ID for the resource. Do not use commas in the Resource ID. If it contains a comma, RoPE will encounter a calculation failure.
Name	Type a unique name for the resource.
Description	Type an optional description for the resource. This can also be powered by the AI Description Optimizer if enabled.
Resource category	Select the category the resource belongs to. Available options: Role, Permission, Account, Software.
Resource type	Select a resource type to associate with the resource. You can only select one resource.
System	Select a system to associate with the resource. You can only select one system.
Child resources	Choose one or more resources to add as a child resource to the resource.
Resource folder	Select a resource folder to associate with the resource. You can only select one resource folder.
Effective owner	Automatically populated by RoPE.
Manual Owners	Select one or more resource owner(s).
Business key	Add a business key for the created resource type.
Classifications	Select one or more classifications for the resource. Available options: Business critical, System administration, Privileged access.
Provisioning depends on	Select another resource that must be provisioned before this one.
Skip provisioning	Select the checkbox to skip provisioning of assignments for this resource. The checkbox is not selected by default.
Resource status	Optionally, select a status for the resource. Available options: Inactive, Active, Obsolete, Disabled.
Valid from	Enter a date from which the resource is valid.
Valid to	Enter a date to specify how long the resource remains valid.
Prevent self-service	Select Yes to prevent the resource from being available for self-service access requests, or No to allow it.
Account types	Choose one or more account types for which the resource is available. If you do not specify anything, the account type(s) are inherited from the resource folder.
Business processes	Select one or more business processes to associate with the resource.
Risk score	The risk score of a permission resource is calculated as: RiskScore(permission) = RiskScore(permission's system) + sum(max(RiskScore(permission's tags per category))). The risk score of a "role" resource is calculated as: RiskScore(role) = max(RiskScore(role's children)).
Risk level	Derived from the risk score.
Policy and risk checks	Select the policy and risk checks that should be executed for the resource.

Technical preview feature: AI Description Optimizer for resources

When resource descriptions are missing or written in technical language, requestors and reviewers risk making decisions they cannot fully understand. The AI Description Optimizer (Cloud) addresses this by enabling resource owners and administrators to generate, review, and apply AI-suggested descriptions for resources. It uses contextual data to generate consistent and meaningful descriptions that can be reviewed and applied by users.

Technical Preview

In the current release, the AI Description Optimizer is provided as a Technical Preview feature only. In Technical Preview, this feature may generate descriptions that require review before use in production environments. We recommend you do not use it in production environments without reviewing the generated descriptions.

This feature requires the EnableAIResourceDescription feature toggle (customer setting) to be enabled. This setting is enabled by default.

You can access the AI Description Optimizer from the resource edit page.

1. From the ellipsis menu, select Generate AI Description.

   

2. In the new window, review the AI-suggested description, compare it with the current description, and choose to apply it or edit it before applying.

   
   important

   • The current description remains unchanged until you apply the final version (either the AI suggestion or your edited version).

   • The AI-generated description is stored in a separate field.

   You must explicitly review and apply the new description. This ensures that AI does not overwrite user-maintained data and that users have full control over whether to use the AI-generated description.

Interface and functionalities of the AI Description Optimizer

The interface contains the following fields:

• AI suggested description – generated based on resource data.
• Current description – existing value stored on the resource.
• Metadata context – information used to generate the suggestion, such as the system, resource type, typical personas, and the primary function.
• Insight method – explanation of how the description was generated.
• Risk validation – information about the risk assessment of the resource.
• Source fidelity – the sources AI used while generating the description.

It also contains the following action buttons:

• Apply AI description – replace the current description with the AI suggestion.
• Apply edited description – save a modified version of the suggestion.
• Cancel – close without applying changes.
• Generate new suggestion – refresh the AI suggestion based on the latest data.

For more information, expand the sections below:

Security: Who can use the AI Description Optimizer

The Generate AI Description action is automatically added to the ellipsis menu in any New UI form view that displays a resource.

It is available to any user who has update permission on the Resource data object type, since applying a generated description modifies the resource. Users without update rights on resources can open the resource view but will not see the action.

Preventing descriptions from being overwritten

Descriptions may be overwritten by imports from connected systems if those systems control the description field. The primary risk is when a connector's import configuration maps a source system field to the description attribute: in that case, the AI-applied description will be overwritten on the next import cycle.

To prevent this:

• Check connector configuration: verify that the import field mapping for the description attribute does not point to a source system value that would overwrite manually maintained descriptions.
• Ensure correct ownership of the description attribute.
• Validate source system data before import.

Auditing and tracking changes

Actions performed using the AI Description Optimizer are logged for audit purposes. This includes:

• Applying AI-generated descriptions.
• Editing and saving descriptions.

Administrators can query AI description activity directly from the database. The relevant data is stored in the aicb.ResourceDescription table, which contains a record of AI-generated descriptions and the actions taken on them.

To request a report of AI generation activity, work with your database administrator to query this table and export the relevant records.

Provisioning descriptions to target systems (OPS field mappings)

When an AI-generated description is applied to a resource, it updates the resource's description in Omada Identity. To propagate that description to target systems (for example, AD group descriptions or SAP role descriptions), you need to configure OPS task mappings.

Source field: RLM_DESCRIPTION

For resource-level provisioning (such as creating or updating groups in AD), the description is exposed through the Resource Lifecycle Management (RLM) data object as the RLM_DESCRIPTION field. This field contains the resource's description from the Enterprise Server and is available in task mappings with Mapping type = Resource.

For details on the RLM_Resource object and its properties, see Omada Provisioning Service – Resource Lifecycle Management.

Configuring the task mapping

1. Open the System onboarding view for the target system.
2. Under the Provisioning section, click Task mappings.
3. Select the relevant task mapping (for example, Active Directory – Security Group) and click Edit.
4. Navigate to the Mappings tab.
5. Click Add mappings and configure:
   • Destination: the target system's description field (for example, description for AD groups).
   • Source: RLM_DESCRIPTION.
   • Operator: Map.
6. Click OK to save.
7. Click Commit settings to push the configuration to OPS. Until you commit, the changes are not applied.

Example: Active Directory

The AD connector data model exposes a description field on AdGroup, AdUser, and AdOrgUnit objects. The out-of-the-box task mapping templates for Security Groups and Distribution Groups use Mapping type = Resource, so you can map RLM_DESCRIPTION > description directly.

Validation

When you commit the configuration, OPS validates that the properties used in the task mapping are available in the involved objects. If the source field is not available, an error message will indicate which property is missing. Verify that:

• The task mapping references the correct source field (RLM_DESCRIPTION for resource mappings).
• The target system's data model includes the destination field.
• Provisioning or synchronization is enabled for the system.

For more information on task mappings, see Provisioning.

Best practices for application roles: how AI-generated descriptions improve access certification, naming conventions, and more

Application roles provide a business-friendly logical layer on top of raw system permissions. The resource owner is accountable for ensuring that the name and description reflect what access is granted in clear and understandable language for requestors, approvers, and access reviewers. The AI Description Optimizer can help achieve this at scale.

Why descriptions matter for application roles

Raw permissions imported from target systems are often not business-friendly and difficult to understand. When descriptions are missing or overly technical:

• Requestors cannot determine whether a resource matches their needs.
• Approvers and reviewers risk rubber-stamping decisions they do not fully understand.
• Access certification surveys generate too many questions without enough context, leading to compliance issues.

Clear descriptions of application roles reduce these risks by making it easier for all participants to understand what access is being granted.

Improving access certification with AI-generated descriptions

During access review surveys, managers and resource owners are asked to confirm or revoke assignments. AI-generated descriptions help reviewers make informed decisions by summarizing what an entitlement allows, based on contextual data such as the system, resource type, and assignment patterns.

Surveys can also be used to identify resources with missing descriptions, missing classifications, or missing owners. Running the AI Description Optimizer before a certification cycle helps ensure that reviewers have the context they need.

Naming and description conventions

• Follow a consistent naming standard across all applications from the beginning (see Naming convention).
• Use the AI Description Optimizer to bring consistency to descriptions that were imported with technical or inconsistent language.
• Ensure each application role has an owner, name, description, and classification before it becomes requestable. Newly imported permissions should not be requestable before they are onboarded to an application role with these attributes ensured.

Role hierarchy considerations

• Maintain a 1:1 mapping between imported permission resources and application roles where possible. Avoid placing multiple permissions in one application role if they are also modeled as individual application roles, as this causes multiple implicit assignments.
• When application roles are organized into enterprise roles, clear descriptions at each level help reviewers understand both the individual permission and the broader business context.
• Implicit role assignments (created when an identity holds all child resources of a role) enable Segregation of Duties (SoD) policies at the role level and support easier reviews, but only if the role descriptions are meaningful.