Roles are objects that assign members to groups in target systems. They exist inside Role models. You can create roles one at a time, or generate them in bulk using Role generators.

To get started, Create a role or Create a role generator.

Each role comprises two parts:

  1. User groups in one or more target systems

  2. User accounts in those target systems to be assigned as members in the groups

The purpose of roles is to manage security and entitlements in a controlled, simplified way. For example, in your organization you might have 10,000+ separate entitlements (application access, software licenses, accounts, file shares, permissions, etc) which are assignable to employees by means of group memberships in your target systems. A NIM role consolidates multiple groups into a single object, so you can grant membership to all the groups at once. For this reason, the number of roles you create in NIM is always significantly less than the number of total groups in your target systems.

How to design your roles is up to you. For most organizations, the most natural design is a 1:1 correspondence of roles to departments and/or job titles. This is easy to implement by using a role generator with a parameterized Role Member Filter. Another common design is one role per combination of variables. For example, in educational organizations, one role for each combination of grades, classes, and buildings. Lookups are often useful for this implementation.


Note that the assignment of entitlements to user groups takes place in the target systems, not in NIM. The roles feature in NIM is strictly about managing the memberships of those groups. Entitlements are thus granted to users indirectly, through their group memberships.

Roles are executed via groupmembership-type operations in Jobs. When your jobs run is when group memberships are actually altered in the target system(s).

Like all other aspects of NIM, roles are soll-ist based. Use the Inspect roles tool to evaluate the current ist and soll.


After you've added a group to at least one role and the role has been executed, NIM now manages that group on an all-or-nothing basis. Any user accounts assigned to the group by means other than a NIM role are removed. This includes accounts assigned to the group via the system's own administration portal. It also includes any groups and/or memberships created with NIM's mapping functions (see Roles vs. group mappings). This removal process is repeated every time the role is executed.

Thus, for each target group, you must decide whether or not NIM will manage it via roles. For groups that NIM will manage, you must:

  • Configure the role's filter to include all necessary users.

  • No longer manage the group's memberships by any other means than NIM roles.

For Active Directory target systems, you should avoid using NIM to manage built-in groups such as Administrators, Backup Operators, Domain Admins, etc.

Roles vs. group mappings

NIM provides two different ways to manage groups and group memberships in target systems:

  • Mappings: Create/update/delete groups and manage group memberships in existing groups.

  • Roles: Manage group memberships in existing groups only.

The most common workflow is using mappings to dynamically create/update/delete groups based on data in your HR system (e.g., departments), and roles to manage the memberships in those groups.

Membership create/delete mapping functions are best used sparingly. For example, when you only need to manage memberships for <5 users and <5 groups. Roles are far more efficient for managing group memberships, especially as the number of users and groups increases.


Do not attempt to manage memberships in a single group using both mappings and roles simultaneously. This will cause conflicts and provisioning errors.