Designing a Least-Privilege Role Model for Multi-Tenant BPO Environments

How-To-Articles
1

Designing a Least-Privilege Role Model for Multi-Tenant BPO Environments

What This Guide Covers

This masterclass details the architectural design of a “Least-Privilege” access model within a Genesys Cloud organization shared by multiple Business Process Outsourcing (BPO) partners or internal business units. By the end of this guide, you will be able to use Divisions and Custom Roles to ensure that supervisors from “BPO A” can only view, manage, and report on their own agents and queues, while remaining completely “blind” to the operations of “BPO B.”

Prerequisites, Roles & Licensing

Designing multi-tenant security requires a foundational understanding of Genesys Cloud’s authorization hierarchy.

  • Licensing: Genesys Cloud CX 1, 2, or 3.
  • Permissions:
    • Security > Division > View/Add
    • Security > Role > View/Add
  • OAuth Scopes: security, authorization.

The Implementation Deep-Dive

1. The Power of “Divisions” (The Security Boundary)

In Genesys Cloud, a Division is the primary boundary for object visibility. Most objects (Queues, Flows, Users, Call Records) can be assigned to a specific division.

Architectural Reasoning:
Do not rely on naming conventions (e.g., BPO_A_Sales_Queue) for security. If a user has the Queue > View permission in the Home division, they see every queue in the org. You must move objects into BPO-specific divisions to enforce isolation.

2. Constructing the “BPO Supervisor” Custom Role

You should never use default roles (like Supervisor) for a multi-tenant environment, as they often contain broad permissions that bypass division boundaries.

Implementation Pattern:
Create a custom role named BPO_Partner_Supervisor.

  1. Grant Least-Privilege Permissions:
    • Routing > Queue > View
    • Analytics > Conversation Detail > View
    • Quality > Evaluation > View/Add
  2. Assign the Role to the User with Division Scoping:
    • Instead of assigning the role “Globally,” assign it only to the Division belonging to their BPO (e.g., Division: BPO_A).

The Result: When this supervisor logs in, the API will only return results for objects within BPO_A. All other BPO data is automatically filtered out at the platform level.

3. Handling “Shared” Resources (Architect Flows & Trunks)

Some resources are often shared across all BPOs, such as the Main IVR Flow or the External SIP Trunks.

The Trap:
Putting the Main IVR in the Home division and giving BPO supervisors access to Home so they can “see” the flow. This breaks the multi-tenancy because they can now see everything in Home.
The Solution: Use Flow-Specific Permissions. Keep the flow in a Shared division and give BPO supervisors Flow > View access only to that specific division, without giving them broader administrative rights.

4. Securing Analytics and Reporting

Multi-tenancy must extend to the reporting layer.

Implementation Step:
When a BPO supervisor runs a report in Analytics > Dashboards, Genesys Cloud automatically applies the division filter. However, for Exported Reports, ensure the “Division” filter is explicitly selected in the report configuration to prevent data leakage from the Home division objects that might not have been correctly categorized.

Validation, Edge Cases & Troubleshooting

Edge Case 1: The “Cross-Division” Transfer

  • The failure condition: An agent in BPO_A needs to transfer a call to a specialist in BPO_B, but they cannot “see” the BPO_B queue in the transfer list.
  • The root cause: Strict division isolation.
  • The solution: Create a Public Directory Division. Move a subset of queues (those intended for transfers) into a division that all agents have View access to. This allows cross-tenant collaboration while keeping sensitive management data (evaluations, specific agent stats) private to the respective BPOs.

Edge Case 2: User Provisioning via SCIM

  • The failure condition: New agents are created via an automated Azure AD sync but are all dumped into the Home division.
  • The root cause: The SCIM payload is missing the divisionId attribute.
  • The solution: Update your SCIM mapping in the Identity Provider to include the urn:ietf:params:scim:schemas:extension:enterprise:2.0:User:divisionId field. Map this to an AD attribute (e.g., department) that contains the correct BPO Division GUID.

Official References