Basic Scenarios with RBAC in IDV Platform

This guide is intended for Platform administrators and other authorized users responsible for configuring role-based user access. It provides practical examples of organizing users into groups, configuring roles and permissions, and managing access across teams and departments.

Basic scenarios:

• Case 1. Configure Access for the First Time
• Case 2. Delegate Role Assignment to an Access Operator
• Case 3. Separate Access Between Departments
• Case 4. Provide Cross-Department Visibility Access
• Case 5. Give a User Access Through Multiple Groups
• Case 6. Assign Multiple Roles to One Group
• Case 7. Update Access When Responsibilities Change

Before You Start

Make sure you understand the key RBAC concepts

This flow outlines the main steps for configuring access and serves as the basis for all scenarios in this guide.

Each scenario demonstrates how to apply the flow to a specific organizational access requirement.

Case 1. Configure Access for the First Time

Use this scenario when your organization has received a new IDV Platform instance and needs to configure access for its employees.

Before exploring the scenarios, review the Role management configuration flow for Admin.

Step 1. Understand initial configuration

The Platform includes a default All Users group.

Every new user is automatically added to this group when their account is created.

The All Users group has no assigned roles and grants no permissions. It cannot be deleted, and you cannot manually assign roles or add members to it.

The Platform provides built-in roles, including Admin role group and Operator.

During the initial Platform setup, the first administrator account is created and added to two groups: All Users group and default Admin group.

The initial administrator can then manage other users, groups, roles, and permissions. To grant administrative access to additional users, the administrator creates their accounts and adds them to the Admin role group. Other authorized administrators can also manage membership in this group.

To provide access to new users, a Platform Administrator adds them to groups with the appropriate roles.

The Platform provides predefined groups and roles. You can also create custom groups and roles to meet your organization's requirements.

The remaining steps in this scenario are primarily intended for the user assigned the Admin role, who will configure roles, groups, and access for other employees.

For details about the available API operations, see the To manage access programmatically, see the OpenAPI Documentation.

Step 2. Define your role structure

Identify the types of users who will work with the Platform and the resources and operations they need to perform their tasks. Review the built-in roles to determine whether they meet these requirements or whether you need to create custom roles.

For example:

User Type	Typical Responsibilities	Suggested Approach
Platform Administrator	Manage Platform configuration, users, groups, roles, and permissions	Review the built-in Admin role
Super User	Manage users, roles, and operational resources with broad permissions	Review the built-in Super User role
Operator	Process verification sessions and perform assigned verification operations	Review the built-in Operator role
Auditor	Review verification data, audit records, and other Platform information	Review the built-in Auditor role
Compliance Manager	Review verification data and manage compliance-related resources, including banlists and cases	Review the built-in Compliance Manager role
Business Flow Administrator	Configure and manage workflows and related business resources	Review the built-in Business Flow Admin role
Technical Administrator	Manage technical configuration, API keys, secrets, and integrations	Review the built-in Tech Admin role
Demo User	Access basic demonstration functionality	Review the built-in Demo role
Access Operator	Assign existing roles to authorized groups without receiving the permissions contained in those roles	Create a custom Access Operator role, as described in Case 2
Department Manager	Manage access to department-specific operational resources	Create a custom role with the required permissions and Entity IDs
Sessions Reviewer	Review sessions and workflows across departments without modifying them	Duplicate the built-in Auditor role and configure a custom Sessions Reviewer role, as described in Case 4

These are example responsibilities, not predefined permission sets. Configure each role according to the tasks and entities your organization requires.

Step 3. Create or edit default roles

Review the existing roles to determine whether they provide the access required by each department. If no suitable role exists, create a custom role or duplicate default roles and then edit them. All instructions see below.

For example, Department A is responsible for processing identity verification sessions using two workflows: Customer Onboarding and Identity Refresh.

Employees in this department need to:

• View sessions associated with these workflows.
• Review session details and verification results.
• Update sessions when required by their responsibilities.
• View the two workflows without modifying them.

To configure this access:

1. Review the existing default roles. If none provides the required access, click Create Role. Or if you have found the default role similar to your needs, you can duplicate and then edit it.
2. Enter Department A role as the name and optionally add a description.

3. In the Permissions section, configure the following permission rows:

   Scope	Operations	Entities
   Sessions	List, Read, Update	Specific sessions assigned to Department A
   Workflows	List, Read	Customer Onboarding, Identity Refresh
   Views	List	Make Sessions page available to view

   If necessary, you can add more permissions, such as ability to download attachments, change status. For the reference of the list of permissions, see Permissions. For detailed instructions, see Configure Role Permissions

4. For each scope, select the corresponding operations and specify the required Entity IDs where supported.

5. Review the permissions and click Save.

Consider the following rules and restrictions:

• Access to sessions also requires access to the relevant workflows. Make sure both scopes are configured.
• It's also necessary to grant the view:list permission to allow viewing the sessions page

The new role defines access to the selected sessions and workflows. Employees do not receive these permissions until the role is assigned to their group.

Step 4. Create groups

Create groups that reflect how you want to assign roles to employees.

For example:

Group	Purpose
Operators	Employees performing verification tasks
Supervisors	Employees supervising verification work
Department A	Employees requiring access to Department A resources
Department B	Employees requiring access to Department B resources
Auditors	Employees responsible for reviewing operational data
Management	Employees requiring broader operational visibility

Example: Create Department A group

Department A employees are responsible for processing identity verification sessions using the Customer Onboarding and Identity Refresh workflows.

To organize these employees and prepare to grant them the permissions configured in Step 3:

1. Navigate to Groups.
2. Click Create Group.
3. Enter Department A as the group name.
4. Optionally, enter a description, such as Employees responsible for processing Customer Onboarding and Identity Refresh verification sessions.
5. Click Create to save the group.

The Department A group is now available. In the next steps, you will assign the Department A role created at Step 3 and add the employees who need this access.

You can create other groups in the same way, depending on your organization's structure. Groups can be created without members or assigned roles.

For detailed instructions, see Create a Group.

Step 5. Assign roles to groups

Assign the appropriate roles to each group.

For example:

• Operators—assign the Operator Role.
• Department A—assign the Department A Role configured in Step 3.
• Department B—assign a role granting access to selected Department B resources.

Example: Assign Department A role

At Step 3, you created the Department A role with permissions to access specific sessions and the Customer Onboarding and Identity Refresh workflows. At Step 4, you created the Department A group.

Now assign the role to the group:

1. Navigate to Groups.
2. Select the Department A group.
3. In Group Details, click Manage Roles.
4. Select Department A role.
5. Save the changes.

The Department A group now has the permissions configured in the Department A role. All current group members inherit these permissions, and any users added later will inherit them automatically.

Repeat this process for the other groups.

Consider the following rules and restrictions:

• A group can have multiple roles. Permissions from all assigned roles are combined.
• You cannot manage role assignments for a group you belong to.

For detailed instructions, see Assign Roles to a Group.

Step 6. Create users and add them to groups

Create accounts for employees who need access to the Platform.

Each new user is automatically added to the All Users group, which grants no permissions. To provide access, add users to groups with the appropriate roles.

Example: Add Department A operator

Suppose an employee in Department A is responsible for reviewing and processing identity verification sessions.

This employee needs permissions from two groups:

• Operators—grants permissions required to perform verification tasks.
• Department A—grants access to the selected sessions and the Customer Onboarding and Identity Refresh workflows configured in Step 3.

To configure the employee's access:

1. Navigate to Users.
2. Create a user for the employee, if an account does not already exist.
3. Navigate to Groups.
4. Open the Operators group and add the employee as a member.
5. Open the Department A group and add the same employee as a member.
6. Save the changes.

The employee now inherits permissions from both groups. The Operators group determines which verification tasks the employee can perform, while the Department A group provides access to the selected department resources.

You can add users to multiple groups as needed. Their permissions are combined, so membership in one group does not restrict access granted through another.

For detailed instructions, see Add Users to a Group.

Step 7. Verify access

After configuring the groups and roles, check the resulting permissions for representative users.

Verify that users can perform the operations required for their work and access the intended resources.

Also check that no other inherited role grants broader access than intended.

For example, a department-specific role cannot restrict access to sessions if another inherited role already grants access to all sessions.

Case 2. Delegate Role Assignment to Access Operator

Use this scenario when you need to delegate role assignment to an employee without granting them administrative or operational access beyond what is required for this task.

For example, an employee is responsible for assigning existing roles to groups across the bank's branches. They do not need to create or edit roles, review verification sessions, or access customer profiles.

The Platform Administrator can configure a custom Access Operator role for this purpose.

Step 1. Identify required permissions

The Access Operator needs to:

• View existing roles.
• Assign and remove roles from groups they are authorized to manage.

They do not need the permissions contained in the roles they assign.

For example, they can assign the Branch 1 Role, which grants access to Branch 1 verification resources, without having access to those resources themselves.

Step 2. Create Access Operator role

As a Platform Administrator:

1. Go to Roles.
2. Click Create Role.
3. Enter Access Operator as the role name.
4. Optionally, add a description.
5. In the Permissions section, configure:
   • roles:read:*—allows viewing all existing roles.
   • role:assign:*—allows assigning and removing roles from groups.
   • roles:list:*-allows viewing the list of roles.
6. Save the role.

For detailed instructions, see Create a Role and Configure Role Permissions.

The Access Operator role does not include permissions to create or edit roles or access operational resources.

Step 3. Create group and assign role

Create a custom group for employees responsible for the role assignments.

1. Go to Groups.
2. Click Create Group.
3. Enter Access Operators as the group name.
4. Assign the Access Operator role.
5. Create the group.

The group is created without members.

For detailed instructions, see Create a Custom Group.

Step 4. Add Access Operator to group

1. Open the Access Operators group from the Groups page.
2. Click Actions, and select Manage Members.
3. Find and select the employee responsible for assigning roles.
4. Click Save.

For detailed instructions, see Add Users to a Group.

The employee now inherits the permissions granted by the Access Operator role.

Step 5. Assign existing role to group

The Access Operator can now assign existing roles to groups they are authorized to access.

For example, to assign the Branch 1 Role to the Branch 1 group:

1. Go to Groups.
2. Open the Branch 1 group.
3. Click Actions, and select Manage Roles.
4. Find and select the Branch 1 Role.
5. Click Save.

The members of the Branch 1 group receive the permissions granted by the assigned role.

For detailed instructions, see Assign Roles to a Group.

Consider the following rules and restrictions:

• The Access Operator must have access to the target group.
• The Access Operator cannot change role assignments for a group they belong to.
• Assigning a role does not grant its permissions to the Access Operator.

Step 6. Verify permissions

Verify that the Access Operator can:

• View existing roles.
• Assign or remove existing roles from authorized groups.
• Assign a role that grants permissions they do not personally possess.

Also verify that the Access Operator cannot:

• Create or edit roles.
• Access verification sessions or other operational resources without the corresponding permissions.
• Manage role assignments for groups they belong to.
• Manage groups they are not authorized to access.

Case 3. Separate Access Between Departments

Use this scenario when several departments should access different operational resources.

For example, Department A and Department B may each have their own sessions, workflows, and profiles.

How department isolation works

The system does not provide a dedicated Department entity.

Instead, you can configure department-specific access by selecting particular Entity IDs in role permissions.

Make sure you understand the main components the permission consists of: Basic Concepts

For supported scopes:

• Specific Entity IDs grant the selected operations for the specified resources.
• All (*) grants the selected operations across all entities of that scope.

Specific Entity IDs can be selected for the following scopes: session, workflow, person, pool, case, group, roles, banlist, iam_application.

However, for the List, Create, and Assign operations, only All (*) is supported, regardless of the scope.

For all other scopes, access applies to all resources within the scope, and specific Entity IDs cannot be selected.

For example, two department managers can have roles with the same permission structure but different Entity IDs:

Role	Scope	Operations	Entities
Department A Manager	Session	Read	Selected Department A session IDs and workflow IDs
Department B Manager	Session	Read	Selected Department B session IDs and workflow IDs

The two roles allow the same operation but apply to different sessions.

This configuration does not automatically guarantee complete department isolation. Other inherited roles and access to self-created entities must also be considered.

Step 1. Identify resources

Identify the resources each department needs.

For example:

• Sessions
• Workflows
• Profiles
• Cases

Determine which resources belong to each department and which can be shared.

Step 2. Create department-specific roles

Create custom roles for the departments.

For example:

• Department A Resources
• Department B Resources

Configure the same required operations in both roles, but select different Entity IDs.

Only use entity-level restrictions for scopes that support selecting specific entities. See Entity-Level Access Control

Step 3. Assign roles to department groups

Create groups and assign their resource-specific roles.

For example:

Group	Assigned role
Department A	Department A Resources
Department B	Department B Resources

Step 4. Add department employees

Add employees to the groups corresponding to their responsibilities.

An operator in Department A might belong to both the Operators and Department A groups.

Ensure the Operator role does not grant unrestricted access to resources that should remain department-specific.

Step 5. Check access to new entities

When a new entity is created, users with wildcard access (the All (*) option, which grants access to all entities within the selected scope for the permitted operations) for the relevant scope and operation can access it through that permission.

Users whose roles grant access only to specific Entity IDs do not automatically receive access to the new entity through those roles.

For example, if a new workflow is created for Department A, a role granting access only to previously selected workflow IDs must be updated to include the new workflow if additional users need access.

The creator retains full access to the entity they created.

If necessary, see Edit Role.

Step 6. Verify department isolation

To check that Department A employees can access the intended Department A resources and cannot access restricted Department B resources, open the Department A group and review its assigned roles.

Repeat the check for Department B.

When evaluating access, consider:

• Every role inherited through every group.
• Wildcard permissions granted by any role.
• Permissions targeting specific Entity IDs.
• Access to entities created by the user.

Case 4. Provide Cross-Department Visibility Access

Use this scenario when auditors, senior managers, or other employees need visibility across multiple departments.

For example, a manager may need to review sessions from all departments without changing them.

Step 1. Identify required operations

Determine which resources the user needs to access and which operations they should perform.

In this example, the manager needs to list and review sessions across all departments without modifying them.

Step 2. Create cross-department role

The Platform provides the built-in Auditor role with broad access to platform data and activity. Since this role grants more permissions than required for this scenario, duplicate it and configure a custom role with restricted permissions.

1. Go to Roles.
2. Open the built-in Auditor role and click Duplicate.
3. Enter a new role name (for example, Sessions Reviewer).
4. Review the copied permissions and keep only the following:

Scope	Operations	Entities
Session	List, Read	All (*)
Workflow	List, Read	All (*)

1. Remove all other permission rows.
2. Save the role.

List allows users to access resource lists, while Read allows them to view resource details. Workflow permissions are also required to view sessions in the Platform.

Do not grant Create, Update, or Delete operations.

Note

Wildcard (All *) access is not restricted by department groups. It applies to all entities within the selected scope for the specified operations.

For detailed instructions, see Duplicate a Role and Edit a Custom Role.

Step 3. Assign role to group

Create the Sessions Reviewers group and assign the Sessions Reviewer role to the group.

Add the employees who need this access.

Step 4. Verify access

Confirm that Session Reviewers can:

• List and review sessions across all departments.
• Access the workflows required to view those sessions.
• View session details without modifying them.

Verify that they cannot create, update, or delete sessions or workflows.

Review any other roles they inherit, because additional roles may grant broader access or operations.

Case 5. Give User Access Through Multiple Groups

Use this scenario when an employee needs permissions associated with more than one responsibility or department.

For example, Alice is an operator in Department A and also assists Department B.

She can belong to three groups:

Group	Purpose
Operators	Grants verification-related permissions
Department A	Grants access to selected Department A resources
Department B	Grants access to selected Department B resources

Alice receives the combined permissions of all roles assigned to these groups.

You do not need to create a separate role containing every permission Alice requires.

Instead, assign existing roles to the appropriate groups and manage Alice's access through her group memberships.

If Alice no longer works with Department B, an authorized user can remove her from the Department B group. She loses permissions inherited only through that group, while retaining permissions granted by her other groups.

Step 1. Review and configure roles

1. Navigate to Roles.
2. Review the existing roles to determine whether they provide the permissions Alice needs.

3. For each required role:

   • If it already provides the required permissions, leave it unchanged and assign it to the appropriate group at Step 2.
   • If it has similar permissions, use Duplicate to create a custom role and adjust its permissions.
   • If no suitable role exists, click Create Role and configure its permissions.

4. Configure the roles as follows:

   Role	Required permissions
   Operator Role	Permissions to perform verification tasks
   Department A Role	List and Read for Sessions and Workflows, with access to specific Department A Entity IDs
   Department B Role	List and Read for Sessions and Workflows, with access to specific Department B Entity IDs

5. If Alice also needs to update sessions, add the Update operation for the appropriate sessions. See Configure permissions

6. Save any new or modified roles.

Make sure that the configured roles do not grant broader access than intended through All (*).

Step 2. Create groups and assign roles

1. Navigate to Groups.
2. Check whether the Operators, Department A, and Department B groups already exist.
3. Create any missing groups using Create Group.
4. Open each group and click Manage Roles.

5. Assign the corresponding role:

   Group	Role to assign
   Operators	Operator Role
   Department A	Department A Role
   Department B	Department B Role

6. Save the changes.

If a group already has the required role, you do not need to assign it again.

Step 3. Add Alice to groups

1. On the Groups page, open the Operators group.
2. In the Actions menu, click Manage Members, select Alice, and save the changes.
3. Repeat the process for the Department A and Department B groups.

Alice now inherits the combined permissions from all three groups.

See Add Users to a Group.

Step 4. Verify Alice's access

1. Navigate to Groups.
2. Open each group Alice belongs to and review its assigned roles.
3. Open the corresponding roles on the Roles page and review their permissions.
4. Check that Alice has:
5. The permissions required to perform verification tasks.
6. Access to the selected Department A sessions and workflows.
7. Access to the selected Department B sessions and workflows.
8. Check that no other assigned roles grant unintended access to additional resources.

Step 5. Update access when responsibilities change

If Alice no longer assists Department B:

1. On the Groups page, open the Department B group.
2. Click Manage Members.
3. Remove Alice from the group and save the changes.

Alice loses permissions inherited only through the Department B group. She retains permissions granted through the Operators and Department A groups.

Note

Alice keeps access to resources she created herself, even after being removed from the group.

Case 6. Assign Multiple Roles to One Group

Use this scenario when all members of a group need several sets of permissions.

For example, the Supervisors group may need:

• A role for verification operations.
• A role for reviewing operational resources.
• A role for permitted group-management tasks.

Instead of combining every permission into one role, assign several existing roles to the group.

All members receive the combined permissions of these roles.

When a role is assigned to or removed from the group, the change affects its members immediately.

Before assigning an additional role, check whether it grants broader access than intended.

Case 7. Update Access When Responsibilities Change

Use this scenario when an employee moves to another department, receives additional responsibilities, or no longer needs certain access.

For example, Bob moves from Department A to Department B.

An authorized user can:

1. Review Bob's current group memberships. See User Details for instructions.
2. Remove Bob from the Department A group. See Remove Users from a Group
3. Add Bob to the Department B group. See Add Users to a Group
4. Keep Bob in the Operators group if his functional responsibilities remain unchanged.
5. Verify his updated access.

Bob loses permissions inherited only through the Department A group and receives permissions through the Department B group.

However, permissions inherited from other groups remain in effect. Bob also retains full access to entities he created himself.

Also see My Groups and Roles.