Custom Roles extend the possibilities and can combine a set of permissions of either existing Nimbus Portal Roles and Admin Roles. Custom Roles are defined as independent configuration entities, to be later applied to any user.
Precondition: Custom Roles can only be created, edited, and assigned in Nimbus Administration UI. The role is then applied in the User Administration. Portal Users and Team Owners don't have access to editing Custom Roles.
Custom Roles configuration entries can be defined with no restriction and applied in the Roles Tab in the User Settings.
The following base properties must be defined before the custom role can be defined further:
| Property | Description |
|---|---|
| Name |
Name of the Custom Role. 💡Note that this will impact how it appears in other parts of the Nimbus UI. |
| Organization Unit |
Organization Unit under which this role will be visible under. 💡 This is particularly relevant when you want to limit availability of certain roles to very specific services and their users. |
| Description |
A short description. 💡This is shown in the listing of all available roles and has no other system effects. |
| Users |
A list of users which currently have this role assigned.
|
💡 Note that you can assign up to 5 Custom Roles to a user.
Creating a Custom Role
Custom roles are defined in several tabs, covered in the following chapters.
General
Here you define the Clear UI Name of the Role as it will appear in the Nimbus UI, the Organization Units visibility and a Description for the role for whenever it appears in listings.
🤔 Thinking about naming conventions
While the name of Custom Roles has no system-relevant function, other administrators will also see them in listings. For those reasons it is useful to agree on naming conventions that orients themselves on common company or business terminology standards. Another way to think about it is to think about features (scope) the role is going to manage.
- Role Naming Examples: Administrator, Supervisor, Organizer, Manager, Coordinator ,…
- Scope Naming Examples: General, Distribution, Extensions, Licenses, Workforce, Agent, User, …
Administration
Allows to individual detail Read, Update, Create, and Delete permissions to the role. While selecting individual permissions, please note the following behavior:
- Selecting certain permissions will automatically create dependencies.
For example: Selecting a Delete permissions will also require View permissions. - Permissions are grouped into areas to allow for easier assignment in bulk.
- Selecting entire groups “inherits down”. Yellow checkboxes will signal that not the full set is inherited (e.g., when exceptions were made).
For further details one each permission, refer to the following tabs:
Services
| UI Area / Tab | Detail Settings | Descriptions and KB links |
|---|---|---|
Services |
Service Administration and related Service Settings. | |
| Services List | Viewing the grid of available services, e.g. within the Service Administration. | |
| General Tab | General Service Settings tab. | |
| General info | Clear / Service Name, PSTN configuration. | |
| Opening Hours | Opening Hours setting application. | |
| Reporting | Settings related to Nimbus Reporting. | |
SLAs and Thresholds |
Adjustment of SLA acceptance. → also see Nimbus KPI Calculations. | |
Visibility |
Steers visibility of reporting data on the Nimbus portal. | |
| Licenses and Addons | Allows to apply licenses according to the contingency shown under License Management. → Also see Nimbus Features related to licenses. | |
| Modalities Tab | Modalities Service Settings. | |
| General info | Setting the supported Modalities. | |
| Audio Video | Audio/Video inbound/outbound settings, Voice Message and Workflows. | |
| Instant Messaging | Instant Messaging, System Messages and Workflows. | |
| External Task | External Task settings and Workflows. | |
| Email settings, Mailboxes, and Workflows. | ||
| Distribution Tab | Access to Distribution Service Settings. | |
| Users | Users Service Settings | |
User Assignment Type |
Adjusting the User Assignment Type. | |
New users immediately active |
Steer if users are immediately “Active” to participate in Nimbus. | |
| Conversations Distribution | Distribution Service Settings, based on MS Teams presence. | |
| Task Priority | Task Priority setting for tasks handled in the service. | |
| ACW | After-Call Work toggle, timings, extensions, timeouts. | |
| Persistent RONA | RONA settings, reset times. | |
| Emergency Routing | Emergency routing case, redirection target. | |
| Extensions Tab | Extensions Service Settings. | |
| Codes | Codes assignment. | |
| Assistant |
Assistant features for services. |
|
| Attendant Console | Conversation Context shown on Attendant Console. | |
| My Sessions | Steer data visibility on My Sessions. | |
Conversation Context URLs |
Allow to assign Conversation Context URLs to show in My Sessions. | |
Store Conversation Context Data |
Storage behavior of Context Parameters and System Fields and Parameters. | |
Keep Custom Context Parameter on Transfer |
Transfer behavior of Context Parameters and System Fields and Parameters on transfer to other users/services. | |
Widgets |
Display or hide specific widgets in My Sessions + detail detail widget configuration. |
|
| Interact Tab | Interact Service Settings. Modalities, Interact Domain Templates (CORS). | |
| Users Tab (MS Teams-based services) | 💡Applies to services with User Assignment Types “MS Teams-based”. → see Service Permissions. |
|
| Default Team Owner Role | Allows to grant Team Owner (Limited) Portal Role to users. | |
| Team member can change active state | (Dis-)allow users to toggle their “Active” service participation. → see User States for more details. | |
| Users list | Shows the list of users (Team Members) within a service | |
Users |
Inherited automatically, same as “Users List” permission above. | |
Role |
Access to Roles User Settings (Limited Team Role assignment for MS Teams-based Services) | |
Active State |
Permission to change the “Active” state toggle for users. | |
| Permissions Tab (Skill-based services) | 💡Applies to services with User Assignment Types “Skill-based”. → see Service Permissions. |
|
| Companion Tab | Allows to access Companion Service Settings to configure enable Speech Recognizers, Transcription and Live Caption. | |
Users
| UI Area / Tab | Detail Settings | Descriptions and KB links |
|---|---|---|
Users |
User Administration and related settings. | |
| Users List | Viewing the grid of available users, e.g., within the User Administration. | |
| General Tab | → see General User Settings. | |
| General Info | Display Name, (most details are retrieved from ID), Organization Unit. | |
| Licenses and Modalities | Also see → License Management. | |
| Services Tab | Allows to see the services the user is a member of. | |
| Roles Tab | Access to Roles User Settings. Allows to assign additional Custom Roles and Portal Roles to users. | |
| Skills Tab | Access to Skills User Settings. Adjust skill and responsibility levels 🔎Used in service Distribution Policies for skill-based distribution. |
|
| Skill Assignment | Allows to assign additional Skills and Responsibilities to users. | |
| Skill Levels | Allows to adjust levels of assigned Skills and Responsibilities. | |
| Profiles Tab | Allows to assign Responsibility Profiles available to the user. 🔎Each profile allows for individual Skills and Responsibilities assignment via the “Skills” tab. |
|
| N/A Reasons Tab | Allows to enable and assign Not Available Reasons visible to users. | |
| Interact Tab |
Interact User Settings. Enable and configure Interact features for users. 🔎 Also see: Use Case - Setting Up Interact. |
|
| Assistant Tab | Access to Assistant User Settings. Allows to configure Assistant features for users 🔎 Also see: Use Case - Setting Up Assistant. |
|
Notes
💡Knowing about RBAC: The roles you assign here use the existing Role-based Access Concept (RBAC) in Nimbus, similar to the existing built-in Admin roles. If you need further details on what each default role permission does, refer to our User Role (RBAC) Matrix. You can also use it as a (naming) reference for your Custom Roles.
☝Be aware of self-elevation - For example: a user is already in a “Organization Unit Administrator” Admin Role within Organization Units A. Now in addition that user gets a Custom Role with the right to change Organization Unit fields within Organization Unit B. If they now edit any user from B and move it to A, they suddenly have full privileges to edit that user, as granted by their original OU Admin role.
→ Suggestion: We advise to limit “General Tab” rights (where OUs are defined) to read-only and in general advise to carefully plan the usage of mixed roles on the same user.