Access and Roles

Identity solution

Turn identity attributes such as department, location, job title, or status into consistent group-based access without managing memberships one by one.

At a glance

NIM role-based access uses roles to define the intended access outcome and role models to determine who qualifies from trusted identity data. Mappings and jobs then apply the resulting group memberships or target-system entitlements consistently instead of relying on one-off manual changes.

Verify success: Generate memberships for a limited test population, inspect the resulting groups and role memberships, then activate the model for routine operation. Use a role-group override only for approved exceptions that should not change the underlying eligibility rule.

Build the solution

1

Define roles
Create roles that describe the access outcome and identify the groups or target-system memberships they manage.

2

Model eligibility
Use role models and source-data criteria to determine which people should receive each role.

3

Test and operationalize
Follow the role-model tutorial to generate memberships, validate results, and put the model into routine operation.

Choose the right access mechanism

Need	Use	Why
Maintain group memberships or recurring entitlement eligibility	Roles and role models	Roles express an ongoing access outcome and can keep memberships aligned as source data changes.
Create, update, disable, or remove a target record directly	Mappings	Mappings apply a defined target-system operation from prepared filter output.
Give baseline access to everyone with the same trusted attributes	A role model with clear eligibility criteria	The model makes the qualification rule visible and repeatable.
Handle an approved exception to the normal rule	Role Group Overrides App	The exception can be controlled without changing the general eligibility logic for everyone else.

Use a filter or role-model rule that an administrator can explain from authoritative data. For example, a department, location, job title, or employment status can be an eligibility input only when the connected source data is current and its meaning is agreed by the implementation team.

Test an access change safely

1. Collect the source and target systems, then confirm the selected person, account, group, and relevant attributes in the Vault.
2. Test the eligibility rule with people who should receive access, should not receive it, and represent an approved exception.
3. Generate or preview the role memberships for a limited population and inspect the target groups or entitlements that would be affected.
4. Run the related job manually and verify the target-system membership or entitlement.
5. Review the job result before enabling the normal sync task schedule.

When a person is missing expected access or receives unexpected access, start with the source attributes and eligibility rule before changing a target group manually. Then use role troubleshooting or provisioning troubleshooting to isolate the affected layer.

For controlled exceptions outside the normal source-data rules, use the Role Group Overrides App. Review role troubleshooting when expected memberships are missing or incorrect.