Genesys Cloud User Management Guide

• Model type: hybrid
• Description: Genesys Cloud uses a role-based access control (RBAC) model combined with division-based access control. Roles are collections of permissions (granular feature-level toggles). Built-in roles (e.g., Admin, Agent, Supervisor, Read Only) are provided out of the box. Administrators can create custom roles with any combination of permissions. Divisions allow scoping of roles to subsets of users, queues, or resources within the organization.
• Custom roles: Yes
• Custom roles plan: Available on all plans
• Granularity: Permissions are defined at the feature and action level (e.g., Routing > Queue > Add, Analytics > Conversation Detail > View). Hundreds of individual permissions are available. Roles can be scoped to specific divisions.

1. Log in to Genesys Cloud and navigate to Admin > People & Permissions > People.
2. Click 'Add Person'.
3. Enter the user's name, email address, and select the appropriate license type (CX tier).
4. Optionally set the user's title, department, manager, and location.
5. Assign one or more roles to the user.
6. Assign the user to one or more divisions if applicable.
7. Click 'Save' to create the user. An activation email is sent to the user's email address.
8. The user must click the activation link in the email to set their password and activate the account.

Required fields: First name, Last name, Email address, License type (CX tier)

Watch out for:

• The activation email expires; if the user does not activate in time, an admin must resend the invitation from the user's profile.
• A user's email address must be unique within the organization and cannot be reused if a previous user with that email was deactivated.
• License seats are consumed immediately upon user creation, not upon first login.
• Assigning a role with permissions that exceed the user's license tier does not grant access to those features; the license tier is the hard ceiling.
• Users are created in the 'Home' division by default; division assignment must be done explicitly if multi-division is in use.

• Can delete users: Verify in tenant
• Delete/deactivate behavior: This app exposes delete operations in its API documentation, but the admin-console path may present removal as deactivation, archiving, or deletion depending on tenant configuration. Confirm whether the UI action is reversible before treating removal as recoverable.

1. Navigate to Admin > People & Permissions > People.
2. Search for and open the user's profile.
3. Click the 'Deactivate' button (or toggle the user's status to 'Inactive').
4. Confirm the deactivation in the dialog prompt.
5. The user is immediately prevented from logging in and their license seat is freed.

Watch out for:

• Deactivated users' email addresses cannot be reused for a new user account; this is a known limitation that causes issues when employees are rehired or change email addresses.
• If a deactivated user owned scheduled reports or callbacks, those may stop functioning and require reassignment before deactivation.
• Deactivation does not automatically reassign the user's active interactions or queue memberships; these must be manually cleaned up.
• SCIM-provisioned users deactivated via IdP are set to inactive in Genesys Cloud but are not deleted; the same no-delete limitation applies.
• License seat release timing may vary by contract; confirm with Genesys account team for billing cycle specifics.

• Where to check usage: Admin > Account Settings > Subscription (shows current license consumption and seat counts by type)
• How to identify unused seats: Navigate to Admin > Account Settings > Subscription to view assigned vs. active seat counts. Cross-reference with Admin > People & Permissions > People filtered by 'Inactive' status to identify deactivated users still counted against seat totals. There is no built-in 'last login' report in the standard UI; Analytics > User Activity reports can be used to identify users with no recent interaction activity.
• Billing notes: Genesys Cloud is billed annually on a per-named-user basis by default. Hourly and concurrent user pricing models are also available under certain contract types. CRM integrations (Salesforce, Dynamics, Zendesk) are add-ons priced separately. AI tokens are included at approximately $250–$350 free per month per org; additional tokens are $1 each. AI bundles are available at $40–$60/agent/month. License tier changes (upgrades/downgrades) must be coordinated with the Genesys account team and take effect per contract terms.

License seats are consumed at user creation, not at first login - delayed onboarding still triggers billing. Every app that routes interactions relies on queue membership and role assignment, both of which are separate manual steps after account creation.

There is no native last-login field in the admin UI; identifying unused seats requires running Analytics > User Activity reports and cross-referencing Admin > Account Settings > Subscription, which adds friction to routine access reviews.

Deactivated users cannot be permanently deleted, and their email addresses cannot be reused - a hard stop when rehiring employees or correcting addresses. Admins must also manually clean up queue memberships and reassign scheduled reports before deactivating a user, or those dependencies break silently.

The most consistent friction points reported by Genesys Cloud admins center on three areas. First, the no-delete, no-email-reuse limitation causes repeated issues during rehires and email corrections.

Second, the absence of a visible last-login field forces teams to build workarounds in Analytics just to run a basic inactive-user audit.

Third, the role and permission model - with hundreds of granular toggles and the interaction between roles and divisions - carries a steep learning curve that slows down initial configuration and ongoing changes alike.

Common complaints:

• SCIM provisioning is unidirectional (IdP to Genesys only); changes made in Genesys Cloud are not synced back to the IdP.
• Deactivated users' email addresses cannot be reused for new accounts, causing friction when rehiring employees or correcting email addresses.
• No permanent user deletion capability; deactivated users accumulate in the system over time.
• No native 'last login' field visible in the admin UI, making it difficult to identify inactive users without running custom analytics queries.
• License seat is consumed at user creation, not at first login, which can lead to unexpected billing if onboarding is delayed.
• Role and permission model has a steep learning curve due to the large number of granular permissions and the interaction between roles and divisions.
• Bulk CSV import has limited field support compared to manual user creation; some attributes must be set individually after import.
• License downgrades require contacting the Genesys account team and cannot be self-served in the admin console.

Manual management is workable for small, stable teams but becomes error-prone at scale. The key constraints to weigh: license tier is a hard ceiling on feature access regardless of role assignment, division scoping must be configured explicitly (users default to Home division), and activation emails expire requiring admin follow-up.

If your IdP is Okta, Azure AD, or ADFS, SCIM provisioning is available on Enterprise plans with SSO configured - it handles core identity sync but leaves routing skills, queue memberships, and role assignments outside its scope.

Bottom line

Genesys Cloud's permission model is powerful but operationally demanding: every named user consumes a full CX-tier seat, role and queue assignment require separate steps after account creation, and deactivation leaves non-reusable records that accumulate over time.

Teams without automated provisioning will feel the overhead most acutely during onboarding waves and offboarding audits, where the lack of a native last-login field and the no-delete limitation create the most manual work.