Set Up Role-Based Access for Multiple Teams in IDV Platform

This guide provides practical scenarios showing how to set up role-based access for multiple teams, manage access as a supervisor, perform verification tasks as an operator, and monitor operations across teams as a headquarters representative.

Before following this guide, make sure you understand the key concepts described in Getting Started and the access configuration procedures explained in Basic Scenarios.

Use the following scenarios to configure and manage role-based access across multiple teams:

• Problem: Multiple Teams Share One Platform
• Before Proceeding
• How to Receive Access Through Multiple Groups
• Configure Access for a Regional Bank
• Example: Configure Access for a Regional Bank
  • Case 1. Set Up Access as a Platform Administrator
  • Case 2. Manage Branch Access as a Supervisor
  • Case 3. Perform Verification Tasks As an Operator
  • Case 4. Monitor Branch Operations as a Headquarters Representative

Problem: Multiple Teams Share One Platform

Consider a large bank with several regional branches. Each branch processes its own customers' verification data.

The bank needs to ensure that:

• Branch operators can perform verification tasks using their branch's sessions, views, and profile pools without accessing restricted data from other branches.
• Branch supervisors can manage their branch's verification processes and provide operators with the required access.
• Headquarters representatives can monitor operational data across branches without managing users, roles, or technical configuration.
• Platform administrators can configure and maintain access across the organization.

Some resources, such as reference lists, may be shared between branches.

The bank can use groups and roles to organize employees, reuse common permissions, and configure access to specific resources where supported.

Consider the following rules and restrictions:

Access restrictions depend on the scopes and entities supported by the Role editor, the combined permissions of all roles assigned to a user, and the user's access to entities they created themselves.

Before Proceeding

For multiple-team access configuration, identify:

• Which employees belong to each team and what responsibilities they have.
• Which resources each team needs to access.
• Which resources should be restricted to a specific team or shared across teams.
• Whether existing roles and groups can be reused.
• Whether the required permission scopes support specific Entity IDs or only All (*).

For details about scopes, operations, entities, and permission inheritance, see Role-Based Access Control .

How to Receive Access Through Multiple Groups

A user can belong to multiple groups. Roles are assigned to groups, so the user receives the roles of every group they belong to, and the permissions of all these roles are combined.

For example, Alice works as an operator in Branch 1. She belongs to two groups:

• Operators—a group with the Operator Role, which provides permissions required to perform verification tasks.
• Branch 1—a custom group with a role that provides access to specific Branch 1 resources.

Alice receives the permissions of both roles.

Similarly, Bob works in Branch 2 and belongs to the Operators and Branch 2 groups.

This allows you to reuse the same functional roles for employees with similar responsibilities and assign additional roles according to the resources they need.

Before proceeding, make sure the required roles and groups are configured. For step-by-step instructions, see Give a User Access Through Multiple Groups.

To configure access for Alice:

1. Navigate to Groups.
2. Open the Operators group, click Manage Members, add Alice, and save the changes.
3. Open the Branch 1 group, click Manage Members, add Alice, and save the changes.
4. Review the roles assigned to both groups to verify that Alice receives the required permissions.

To configure access for Bob, follow the same steps, adding him to the Operators and Branch 2 groups.

See Add Users to a Group for detailed instructions.

Permissions are additive

Permissions from different roles are always combined. There are no deny permissions, and one role cannot restrict access granted by another.

For example, if the Operator Role grants access to all sessions, another role granting access to specific Branch 1 sessions cannot restrict Alice's access to Branch 1 sessions.

To restrict access to specific sessions, make sure none of the user's other roles grants broader access.

Access to entities created by user

In addition to the permissions received through roles, users have full access to entities they created themselves.

This access does not depend on their roles and cannot be restricted by them.

For example, even if Alice's roles grant access only to selected Branch 1 sessions, she can also access sessions she created herself outside that selection.

When configuring access for separate branches, consider both inherited role permissions and access to self-created entities.

Example: Configure Access for Regional Bank

In this example, the bank has three regional branches and a headquarters team.

The bank needs four types of users:

User type	Responsibilities
Platform Administrator	Configures users, groups, roles, and permissions across the bank.
Branch Supervisor	Manages branch operations and permitted access-management tasks.
Branch Operator	Reviews verification sessions and performs assigned actions.
Headquarters Representative	Monitors operational data across branches without administrative access.

The following sections explain how to configure and use access for each user type.

Case 1. Set Up Access as Platform Administrator

As a Platform Administrator, you establish the initial role-based access structure for the bank.

You need to organize employees into groups, configure roles, and assign permissions for each team's responsibilities and resources.

Step 1. Identify users and required access

Identify the employees who need access and the tasks they will perform.

For example, Branch 1 has one supervisor and 15 operators.

The operators need similar functionality, but they should access only the resources required for their branch.

Instead of creating a separate functional role for every branch, you can use common functional groups and separate branch groups.

When planning this structure, make sure that shared functional roles do not grant broader resource access than intended.

Step 2. Create groups

Check whether suitable groups already exist.

If an existing group meets your requirements, proceed to the next step. Otherwise, create a new group as needed.

For example:

Group	Purpose
Operators	Employees who perform verification tasks.
Supervisors	Employees who manage branch operations.
Branch 1	Employees who need access to Branch 1 resources.
Branch 2	Employees who need access to Branch 2 resources.
Branch 3	Employees who need access to Branch 3 resources.
Headquarters	Employees who need access to operational resources across branches.

You can create groups without adding users or assigning roles immediately.

To create a group:

1. Go to Settings.
2. Click Team, and select Groups.
3. Click Create Group.
4. Enter a unique group name, such as Operators.
5. Optionally, enter a description.
6. Create the group.

For detailed instructions, see Create a Group. Repeat these steps for the remaining groups.

Step 3. Review existing roles

Before creating new roles, check whether suitable roles already exist.

1. Go to Settings.
2. Click Team, and select Roles.
3. Review the available roles.
4. Open a role to check its permissions.
5. Determine whether the role provides the required access.

For detailed instructions, see View Roles.

If a suitable role exists, go to step 5 below.

If no suitable role exists, create a custom role or duplicate a role with similar permissions, and edit it.

When reviewing an existing role, check both the operations it grants and the specific resources it allows users to access.

• If the role provides exactly the required access, reuse it and proceed to Step 5.
• If the role grants broader access than required, duplicate it and edit the copy to restrict permissions to the appropriate resources.
• If no suitable role exists, create a custom role.

Consider the following rules and restrictions:

• Avoid modifying an existing role that is already assigned to other groups unless you intend to change permissions for all its members.

Step 4. Create roles and configure permissions

Create roles that define the tasks employees can perform and the resources they can access.

For example:

Role	Purpose
Operator Role	Provides permissions required to perform verification tasks.
Supervisor Role	Provides permissions required to manage branch operations and permitted access-management tasks.
Branch 1 Role	Provides access to selected Branch 1 resources for supported scopes.
Branch 2 Role	Provides access to selected Branch 2 resources for supported scopes.
Branch 3 Role	Provides access to selected Branch 3 resources for supported scopes.
Headquarters Role	Provides operational access across branches without user or role management permissions.

Example: Configure Operator role

Operators in all branches need to open the Sessions and Workflows pages as well as have access to Views. However, they should only view and update sessions belonging to their own branch.

First, create a shared Operator Role that provides access to the required Platform pages.

1. Navigate to Roles.
2. Click Create Role.
3. Enter Operator Role as the role name.
4. Optionally, enter a description, such as Provides access to Platform features required for verification tasks.
5. In the Permissions section, configure the first permission row:
   • Scope: Sessions
   • Operations: List
   • Entities: All (*)
6. Add another permission row:
   • Scope: Workflows
   • Operations: List
   • Entities: All (*)
7. Add another permission row:
   • Scope: Views
   • Operations: List
   • Entities: All (*)
8. Click Save.

The Operator Role now provides access to the Sessions, Workflows, and Views pages without granting permission to view or update the details of all sessions and workflows.

Example: Configure Branch 1 role

Next, create a role that grants access to the sessions and workflows assigned to Branch 1.

1. On the Roles page, click Create Role.
2. Enter Branch 1 Role as the role name.
3. Optionally, enter a description, such as Provides access to Branch 1 verification resources.
4. In the Permissions section, configure the first permission row:
   • Scope: Sessions
   • Operations: Read, Update
   • Entities: Select the Entity IDs of the sessions assigned to Branch 1.
5. Add another permission row:
   • Scope: Workflows
   • Operations: Read
   • Entities: Select the Entity IDs of the workflows used by Branch 1.
6. Add another permission row:
   • Scope: Views
   • Operations: List
   • Entities: Select the Entity IDs of the workflows used by Branch 1.
7. Click Save.

The Branch 1 Role grants access to the selected sessions and workflows. When an operator receives both the Operator Role and Branch 1 Role through group membership, they can open the relevant pages and work with the authorized Branch 1 resources.

Example: Configure Branch 2 and Branch 3 roles

Repeat the Branch 1 configuration for the other branches, using their respective Entity IDs.

Role	Scope	Operations	Entities
Branch 2 Role	Sessions	Read, Update	Specific Branch 2 session IDs
Branch 2 Role	Workflows	Read	Specific Branch 2 workflow IDs
Branch 3 Role	Sessions	Read, Update	Specific Branch 3 session IDs
Branch 3 Role	Workflows	Read	Specific Branch 3 workflow IDs

Configure the Supervisor Role and Headquarters Role according to their responsibilities.

Consider the following rules and restrictions:

• Do not grant Read or Update for All (*) sessions through the shared Operator Role. This would give operators access to sessions across all branches.
• Permissions from multiple roles are combined. A branch-specific role cannot restrict broader access granted by another role.
• Access to Sessions also depends on access to the relevant Workflows.
• Selecting specific session Entity IDs does not automatically grant access to new sessions created later.

For detailed instructions, see Configure Role Permissions.

For the complete list of available scopes and operations, see Permissions

Step 5. Assign roles to groups

After configuring the roles, assign them to the appropriate groups.

To assign roles:

1. Go to Groups.
2. Click the required group to open Group Details.
3. Select Actions and click Manage Roles.
4. Select the roles you want to assign.
5. Review the information about how the changes will affect group members.
6. Save your changes.

For detailed instructions, see Assign Roles.

For example:

Group	Assigned role
Operators	Operator Role
Supervisors	Supervisor Role
Branch 1	Branch 1 Role
Branch 2	Branch 2 Role
Branch 3	Branch 3 Role
Headquarters	Headquarters Role

You can assign multiple roles to a group.

Assigned roles apply immediately to all current group members. Users who join the group later receive the same roles automatically.

Note

For administrators:

Assigning a role requires roles:assign:<role_id> or roles:assign:*. A user cannot manage the role assignments of a group they belong to.

Step 6. Add users to groups

After assigning roles, add employees to the appropriate groups.

If an employee does not have a Platform account, create one first. See Create a User.

To add users:

1. Go to Settings, click Team, select Groups.
2. Open the required group.
3. Select Manage Members.
4. Add the employees who belong to the group.
5. Save your changes.

For detailed instructions, see Add Users to Groups.

For example:

User	Group memberships
Alice, Branch 1 Operator	Operators, Branch 1
Bob, Branch 2 Operator	Operators, Branch 2
Carol, Branch 1 Supervisor	Supervisors, Branch 1
David, Headquarters Representative	Headquarters

Alice receives the permissions granted by both the Operator Role and Branch 1 Role.

Bob receives the permissions granted by the Operator Role and Branch 2 Role.

Carol receives the permissions granted by the Supervisor Role and Branch 1 Role.

David receives the permissions granted by the Headquarters Role.

Consider the following rules and restrictions:

• Users receive the combined permissions of all their roles. Membership in a branch group does not limit access granted by another group.

Step 7. Verify access

Check the effective permissions for representative users from each team.

For example:

• Alice can perform the required verification operations and access the Branch 1 resources permitted by her combined roles.
• Bob can perform the required verification operations and access the Branch 2 resources permitted by his combined roles.
• Carol can manage Branch 1 operations and perform the access-management tasks permitted by her roles.
• David can access the required operational resources across branches without administrative permissions.

Also verify that users cannot access restricted resources belonging to other branches, except where access is granted through another role or through the user's ownership of an entity they created.

Because permissions accumulate, check every role inherited through the user's group memberships.

If a user has more access than intended, review all their assigned groups and the permissions configured in the associated roles.

Case 2. Manage Branch Access as Supervisor

As a Branch Supervisor, you manage your branch's verification processes and the access-management tasks permitted by your role.

For example, Branch 1 introduces a new KYC process. Fifteen operators need to monitor verification sessions and manually approve them.

You need to provide the operators with the required access without granting access to restricted resources from other branches.

Step 1. Check your permissions

Before configuring access, make sure you have permission to manage the relevant groups, create or configure roles if needed, and assign roles to groups.

See how to view your assigned roles.

Note

For administrators: refer to the list of permissions

Step 2. Identify users and required resources

Identify the 15 operators who need access to the new KYC process.

Determine:

• Which workflow handles the new KYC process.
• Which sessions operators need to monitor and process.
• Which view operators will use to monitor those sessions.
• Which operations operators need to perform, including reviewing and manually approving verification sessions.

For example, operators need access to the Branch 1 KYC workflow, its verification sessions, and the Branch 1 KYC Monitoring view.

Note

For administrators:

Assigning a role requires roles:assign:<role_id> or roles:assign:*. A user cannot manage the role assignments of a group they belong to.

Step 3. Create group

Check whether an existing group contains the intended operators and can be used to grant access to the new KYC process. See how to view group details.

For example, 15 operators may already belong to the Operators and Branch 1 groups.

If the additional permissions should apply only to these 15 operators, create a separate group named Branch 1 KYC Reviewers.

This allows you to grant access to the new process without changing permissions for all operators in Branch 1.

To create the group:

1. Navigate to Groups.
2. Click Create Group.
3. Enter Branch 1 KYC Reviewers as the group name.
4. Optionally, enter a description, such as Operators authorized to review and manually approve Branch 1 KYC sessions.
5. Leave Roles empty for now.
6. Save the group.

The group can be created without assigned roles.

If a suitable group already exists, reuse it and proceed to Step 4.

For detailed instructions, see Create a Group.

Step 4. Review existing roles

Check whether an existing role provides the permissions operators need to monitor and manually approve verification sessions in the new KYC process.

To review existing roles:

1. Navigate to Roles.
2. Find a role that may provide the required access, such as an existing KYC review role.
3. Open the role to view Role Details.
4. Review its configured permissions:
   • Scope—check whether the role covers Sessions, Workflows, Views, and any other required resources.
   • Operations—check whether the role permits operators to view sessions and perform the required approval actions.
   • Entities—check whether the role grants access to the resources associated with the Branch 1 KYC process.
5. Check which groups already have the role assigned. Consider whether changing the role would affect other users.

Based on your review:

• If a suitable role exists, reuse it and proceed to Step 6.
• If a similar role exists, duplicate the role, adjust its permissions, and proceed to Step 6.
• If no suitable role exists, create a new Custom role in Step 5.

If you do not have the required permissions to create or configure roles, contact your Platform Administrator.

Step 5. Create and configure role

If no suitable role exists, create a custom role named Branch 1 KYC Review.

To create the role:

1. Navigate to Roles.
2. Click Create Role.
3. Enter Branch 1 KYC Review as the role name.
4. Optionally, enter a description, such as Provides access to review and manually approve Branch 1 KYC verification sessions.

5. In the Permissions section, configure the following permissions for Sessions:

   • List—select All (*) in the Entities field.
   • Read, Update—select the IDs of the sessions operators are authorized to process.

6. Configure the following permissions for Workflows:

   • List—select All (*) in the Entities field.
   • Read—select the Branch 1 KYC workflow ID in the Entities field.

7. Configure the following permissions for Views:

   • List—select All (*) in the Entities field.
   • Read—select the Branch 1 KYC Monitoring view ID in the Entities field.

8. Add any additional permissions required to perform manual approval actions.

9. Review the configured permissions and click Save.

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

The Role Details page opens for the new role.

The following table summarizes the required access:

Scope	Operations	Entities
Sessions	List, Read, Update	Sessions operators are authorized to process
Workflows	List, Read	Branch 1 KYC workflow for Read
Views	List, Read	Branch 1 KYC Monitoring view for Read

For Sessions, configure the supported entity access that covers the sessions operators need to process. The table describes the intended access, not a literal Entities field value.

Consider the following rules and restrictions:

• The Branch 1 KYC Monitoring view determines which sessions are displayed. Access to the view does not by itself grant permission to read or update every session displayed in it.
• List provides access to the corresponding page or list. Read and Update determine access to authorized entities.
• If you select specific session IDs, access is limited to those sessions. Make sure the configuration also supports access to new KYC sessions when required.
• Do not grant access to All (*) sessions if operators must be restricted to Branch 1, unless other supported access controls enforce that restriction.
• Permissions from multiple roles are combined. Check that other roles do not grant broader access than intended.

You can grant only permissions you already possess.

Step 6. Assign role to group

Assign the new or existing role to the group whose members need access to the KYC process.

1. Navigate to Groups.
2. Open the required group, such as Branch 1 KYC Reviewers.
3. Click Actions and select Manage Roles.
4. Select Branch 1 KYC Review or the suitable existing role identified in Step 4.
5. Click Save.

All current group members inherit the permissions granted by the assigned role. Users added to the group later inherit these permissions as well.

Note

You cannot manage role assignments for a group you belong to. If this restriction applies, contact another authorized administrator.

For detailed instructions, see Assign Roles to a Group.

Step 7. Add operators to group

If the group does not already contain the 15 operators:

1. Navigate to Groups.
2. Open Branch 1 KYC Reviewers.
3. Select Manage Members.
4. Add the 15 operators who need access to the new KYC process.
5. Save your changes.

The operators keep the permissions from their other groups and gain additional permissions through the roles assigned to Branch 1 KYC Reviewers.

Before adding users, verify that the group has only the roles intended for these operators.

For detailed instructions, see Add Users to a Group.

Step 8. Verify access

After configuring the group and role assignments, verify that the operators have the intended access.

Check that operators can:

• Open the Branch 1 KYC Monitoring view.
• Access the verification sessions associated with the Branch 1 KYC process.
• Review session details and verification results.
• Perform the permitted manual approval actions.
• Access new KYC sessions when required by the process.

Also verify that operators cannot access restricted resources belonging to other branches unless those resources are covered by another assigned role or Creator Ownership.

If an operator has more or less access than intended:

1. Review all groups the operator belongs to.
2. Review the roles assigned to those groups.
3. Check the scopes, operations, and Entity IDs configured in each role.
4. Check whether any role grants access to All (*) entities.
5. Review any access provided through Creator Ownership.
6. Adjust the configuration as needed and verify access again.

Remember: Permissions are additive. Assigning a role with access limited to Branch 1 does not restrict broader permissions granted through another role.

Case 3. Perform Verification Tasks as Operator

As a Branch Operator, you perform day-to-day verification tasks using the resources available to you.

For example, you may need to review verification results, inspect sessions or profiles, and approve or reject verification sessions.

You receive access through your group memberships.

Step 1. Confirm your access

Make sure your Platform Administrator or Branch Supervisor has added you to the appropriate groups.

See how to view your assigned roles.

For example, if you work in Branch 1, you may belong to:

• Operators, which provides operational permissions.
• Branch 1, which provides permissions for selected Branch 1 resources.

You inherit permissions from both groups.

If you cannot access the required resources, contact your Branch Supervisor or Platform Administrator.

If you are a Platform Administrator, consider the following recommendations:

• To allow operators to perform verification tasks, configure the following permissions in the roles assigned to their groups:

  Scope	Operations	Entities
  Sessions	List	All (*)
  Sessions	Read, Update	Sessions the operator is authorized to process
  Workflows	List	All (*)
  Workflows	Read	Workflows used for verification
  Views	List	All (*)
  Views	Read	Views used to monitor verification sessions

• Configure entity-level access according to the operator's responsibilities. For example, Branch 1 operators should have access to the required Branch 1 resources.

• List provides access to the corresponding page or list. Read allows users to view authorized entities, and Update allows permitted changes to sessions.

• Permissions from multiple roles are combined. Make sure other assigned roles do not grant broader access than intended.

For descriptions of the available operations, see Operations.

Step 2. Open your assigned resources

Open the view or session list used for your branch's verification process.

For example, open the view configured for Branch 1 KYC verification.

You can access resources permitted by your combined role permissions, as well as entities you created yourself.

Step 3. Review verification sessions

Open a session and review the available verification information.

Perform the actions permitted by your roles.

For example, you may need to approve or reject a verification session after reviewing its results.

Step 4. Request additional access if needed

If you cannot access a required session, view, or profile, or cannot perform a required action, contact your Branch Supervisor or Platform Administrator.

They can review your group memberships and the permissions configured for the assigned roles.

Case 4. Monitor Branch Operations as Headquarters Representative

As a Headquarters Representative, you need access to operational data across branches without managing users, roles, or technical configuration.

For example, you may need to monitor verification activity across all regional branches.

Step 1. Confirm your access

Make sure your Platform Administrator has added you to the Headquarters group.

The roles assigned to that group determine which operational resources you can access.

If you are a Platform Administrator, consider the following recommendations:

• To provide a Headquarters Representative with read-only access to operational data across branches, configure the following permissions in a role assigned to the Headquarters group:

  Scope	Operations	Entities
  Sessions	List, Read	All (*)
  Workflows	List, Read	All (*)
  Profiles	List, Read	All (*)
  Views	List, Read	All (*)

• Add permissions for other operational resources if required.

• Do not grant permissions to create, update, or delete users, roles, groups, or technical configuration unless explicitly required.
• For descriptions of the available operations, see Operations.

Step 2. Open operational resources

Open the views, sessions, profiles available to you.

For example, you may need to review verification activity across Branch 1, Branch 2, and Branch 3.

Your access depends on the scopes, operations, and entities configured in your inherited roles, together with access to entities you created yourself.

Step 3. Request additional access if needed

If you cannot access the required operational information, contact your Platform Administrator.

The administrator can review the permissions granted by the roles assigned to your groups.

Result

You have configured role-based access for multiple teams within one IDV Platform instance.

• Platform Administrators configure and maintain the access structure across the bank.
• Branch Supervisors manage permitted operations and provide access through groups and roles.
• Branch Operators perform verification tasks using their inherited permissions.
• Headquarters Representatives monitor permitted operational data across branches.

By separating functional and resource-specific permissions, you can reuse roles across teams while controlling access to specific resources where supported.

Remember that permissions are additive and users retain access to entities they created themselves.

When the bank adds another branch or introduces a new verification process, follow the same workflow:

1. Identify users and required access.
2. Reuse or create groups.
3. Review existing roles.
4. Create or edit roles and configure permissions if necessary.
5. Assign roles to groups.
6. Add users to groups.
7. Verify the combined permissions.