Luware Knowledge

Nimbus Portal Nimbus Admin Nimbus Release Notes Luware Cloud Status
Home Nimbus Administration User Administration

User Administration

The "Users" view allows administrators to search, create and configure Nimbus users. It consists of the following elements:

  • A user list with search, filter and create options. 💡The availability of Nimbus users is directly tied to your (Azure) user directory. You can search users by common or unique criteria such as @domain or their O365 ID.
  • A user detail view, opened when clicking on or creating a user. The view is distinguished by several tabs as explained further below.

Filtering

When your current Nimbus view offers filters:

  • Click the filter icon for a filter selection menu.
  • Click on a filter name to directly add it and start.
  • Click the toggles to show or hide a filter.

When filters are already active:

Unless “All” is shown as filter content, your results are filtered.

  • Click ✖ inside a filter to clear its contents.
  • The filter itself will remain available for use.
  • To hide a filter again, use the filter menu. 
    ⮑ Doing so will also clear the filter from your search results.

Overview - User Listing

The table of existing users lists the following details:

Column Description / Purpose
Display Name Clear Name of the user - as shown to other users 
Organization Unit

All items (including services) in Nimbus are structured into Organization Units (OU). The user's OU also determines:
UPN User Principal Name to which calls get forwarded to by Nimbus services.
O365 ID Unique Azure / O365 ID under which the user is identified by.
Department Department field (blank if not specified within Azure). 
Attendant Console enabled Shows if an Attendant Console license is enabled for this user. This is a separate Luware application that can also run within the Nimbus Portal UI. 
Active Profile Shows the currently active Responsibility Profile for that user. Primarily used to indicate Contact Center participation.
Number of routing services Shows the amount of services that this user is a part of.

Managing Users

Nimbus retrieves all users from your local O365 user directory. Creating a user means that Nimbus assigns User Roles and Groups for that user, as well as define criteria used from call distribution to that user.

Creating Users

Create User

In order to allow a new User access to the Nimbus UI (either Portal or Admin functionality), the User needs to be made known as a configurable and referable data entity in Nimbus.

💡Access to your User Directory (Entra ID)

Precondition: As stated in our Nimbus App Permissions Nimbus uses delegated permissions to search for Users in your Microsoft Entra ID. If these permissions are granted by a Tenant Administrator, any of the existing Nimbus Admin Roles – e.g. a delegated Tenant Administrator – can search for and add a User using their display name. 

An example User being added into Nimbus. Identification fields such as First Name, Last Name, UPN and O365 ID are directly read from Entra ID.

💡Regardless of the way you add Services and Users to Nimbus, your Entra ID User directory remains the "source of truth".

⮑ Once the User is added, Nimbus uses the O365 ID for internal mapping and User identification. All other Data will be synchronized (UPN, First Name, Last Name, Avatar, etc.) and made available for internal search, e.g. via Attendant Console to perform call transfers.

 

Considerations before creating Users

Any User that already exists in any Nimbus Service does not need to be recreated / added again. Their user account be upgraded for further licenses and Use Cases. A User can act in multiple different Roles simultaneously.

🤔 Does Nimbus create or change any existing Users?

Nimbus by itself does not create new Users in your directory, nor will it write over any existing fields. Users are authenticated using the Organization Units and Role Access Concept, with Entra ID (O365 ID) and Single-Sign-On details as verification “source of truth”.

Service to User assignment

User Assignment Types

INC User Assignment Types

Each Nimbus service can be of a different user assignment type that determines how users are associated to this service:

  • MS Teams-based: Directly tied to your MS Teams "Teams" as determined during Service Provisioning. Users get automatically added and synced to a Nimbus service.
  • Skill-based: Applies for manually created services via Service Administration. Requires skill-assignment from users you assign to the service from within your tenant directory.
  • None: Has no users, but can be configured by any administrator. Used for IVR or first-level redirection services. 

☝ Important to know: The user assignment type is fixated when a service was either provisioned via MS Teams or manually created via Service Administration, e.g. for IVR or skill-based distribution purposes. A switch between MS Teams-based and Skill-based services is not possible due to how individual users are configured and how Nimbus Features operate.

 

 

🤔 Is user assignment tied to licensing?

The method of user assignment per Service type, and related feature licenses not co-dependent on a technical level. However certain ways of managing user permissions may be preferrable, depending on your requirements and how you provision new services in future.

User Assignment Advanced Routing

Enterprise Routing

Contact Center

 Description
MS Teams-based  ✅ ✅ 🔍 Relevant if you want to stick to MS Teams-based user sync but use Contact Center  Features 

MS Teams-based user assignment is the most common scenario for new Advanced Routing and Enterprise Routing licensed services.

Permissions are automatically determined by the role in the MS Teams channel, minimizing the administrative effort to onboard and configure new users.
None ✅ ✅ ✅ Services with user assignment type "none" are generally used for IVR or automated redirection. They can be created manually and out outside of an MS Teams channel restriction
Skill-based ❌ ❌ ✅

The main use case for Contact Center services is setting up Distribution Policies to escalate calls based on Skills and Responsibilities.

The Distribution Order guarantees that users get selected in a very targeted manner.

With adjustments of their skills and Duty Profiles users can opt-in or out of certain distribution policies, e.g. based on time of day, workload, current responsibilities.

Adding and removing of users is very flexible, e.g. across departments and outside of MS Team-based constraints.
 
 

🤔 How does this affect my service operation?

Yes the user assignment greatly determines how a service (and its users) are managed and interact with each other in future.

💡 MS Teams-based services are tied to one dedicated channel in the Teams client. 

The Service name and all channel users are in sync with and actively used by Nimbus for task distribution. Most interaction is tied to the channels within that team, e.g. Voice Messages, General chat.

💡 Skill-based services allow users to participate in multiple services simultaneously.

  • The individual services are NOT tied to using MS Teams channels as central point of communication and user management. The removal of a dedicated Teams channel also removes the possibility for a single channel for Voice Messages, also opening up potential data access and GDPR compliance risks.
  • Skill-based services also add configuration complexity:
    • Users on skill-based services are managed via Agent Service Settings per service. This can be done by any team owner.
    • Optionally users can get Skills and Responsibilities assigned for escalated service task distribution. A Distribution Policy assigned to each service determines how new incoming tasks are distributed among users, depending on their responsibility and expertise.
    • 💡 Good to know: Users are also not "Active" on skill-based services per default. Instead, they control their own service availability via configurable Responsibility Profiles.

💡None - Services with no users assigned 

These services do not have users nor a specific MS Teams channel, and therefore don't use most of the abovementioned features. They only act as “gateway”, e.g. to route customers to actual services via IVR.

 
 

🤔 Does user assignment affect available features?

Yes, because certain features cannot operate “outside” of a given MS Teams channel context. While technically independent from the chosen service type (license) the user assignment type mandates which Nimbus Features are available. Here are some examples:

Feature User Assignment Type ► MS Teams based Skill- based None
Workflow configuration Adaptive Cards ✅ - -
Voice message ✅ - -
Service Settings Voice message channel ✅ - -
Extensions tab ✅ ✅ -
Conversations Distribution section ✅ ✅ -
Setting of a Distribution Policy - ✅ -
New users immediately active ✅ - -
Reporting section ✅ ✅ -
Editable "Name" field on Service Settings - ✅ ✅
Frontend UI "Active" toggle for users ✅ - -
Users switching Duty States / Responsibility Profiles  - ✅ -
 
 
 
 

🤔 When should I create Nimbus Users manually?

This depends on the Nimbus Features you want to enable for your Users. Here are some example Use Cases:

Use Case Description
Contact Center Agent In case you want to create a Contact Center service without a direct MS Teams "Team" connection you can add Users manually by searching within your O365/Azure User directory. By individually assigning Contact Center licenses to those Users you enable Skills and Responsibilities for skill-based distribution within any (future) Contact Center service type.
Frontpage Support / First Contact  Some Users may not directly participate in a Nimbus service, but use Luware Interact to directly communicate with customers via embedded Website widget. These Users need to be added to the Nimbus list before setting up Interact.
Custom Role You may want assign a Contact Center license to a single User, e.g. to grant them Custom Roles valid within specific Organization Units. This gives you full control over which permissions this User actually has.

💡Access to Service data: Manually added Users will get login access to the Nimbus Portal, but may not see any relevant reporting data until they are part of at least one service.

 
 

Adding a User manually

The default way to create a new User in Nimbus is as follows:

  1. Access the Admin Portal > Users List and click “Create New”.
  2. In the creation dialog, search for the O365 Display Name or UPN of the User, as specified in your Microsoft 365 Admin Center > Users section.
  3. Specify an Organization Unit for this new User.
  4. Click “Create” and wait for the process to complete.
    ⮑ The new User is now ready to log into the Nimbus Portal. Note that Portal Roles are granted when the User is added to a Service, either via MS-Teams (as part of the related Team), or manually in a Nimbus Contact Center Service.

☝ Knowing about Organization Units: The Organization Unit (OU) concept is essential throughout Nimbus. The OU will determine where your User is visible for selection within Nimbus configuration-related UIs, e.g. when other Service Owners want to search for and add the User to their roster.

💡 Good to know: You can change the OU of a User later at any time if necessary. Any existing references (e.g. Nimbus Service assignments) will remain intact until the User is removed (either by a Service Owner or from your Entra ID directory).

 

Adding User through MS Teams-based Service

After following the Service Provisioning steps you can add Nimbus directly via MS-Teams. The corresponding Users will be automatically added into Nimbus and get assigned Portal Roles automatically.

MS-Teams based Nimbus Services will automatically onboard new MS Team Members and Owners as Service Users

Manual User assignments

💡 Good to know: Nimbus knows multiple ways of User Assignment. As an example, you can manually create additional Nimbus Services which are not tied to an MS Teams channel. Such services can share Users across multiple departments or regions (Contact Center), or have no Users at all (e.g. IVR and rerouting Services).

Manual User assignment allows for more detailed Portal Roles 

🔎 For more information refer to:

 

User Provisioning via Nimbus API

When adding a User via Nimbus API, there is no search possible in your Microsoft Entra ID. You need to retrieve and use O365 IDs manually, which are then sent to Nimbus. Refer to Step 3 - Using the API for instructions on how to create empty Users:

Learn more….

Nimbus API

The Nimbus Public REST API allows to provision blank users. This page describes the setup and usage procedures.

💡If you have already set up Azure and Nimbus for using the API, you can directly go to → Step 3 - Using the API for instructions on how to create empty users.

PRECONDITIONS

On this page the following topics are covered: 

  1. Check if the API was enabled on your Provisioning Tenant Settings. This feature is enabled by a Luware System Administrator. 
  2. Set up the Nimbus App Registration and necessary API Permissions in Azure. 
    As a Tenant Administrator you can perform these steps below in parallel.
 

Step 1 - Azure Setup

✅ Tenant Administrator: The following steps need to be done with Tenant Administrator privileges. You will grant some of the Nimbus App Permissions to be used later via the API.

Create App registration

🔎 Also see: Quickstart: Register an application with the Microsoft identity platform | Microsoft Learn

  1. Go to Portal.Azure.com
  2. In your Tenant, Create an App registration, e.g. “My Nimbus App” 
  3. Leave the other options as they are.
Nimbus App Registration

Grant API Web Access Permissions

🔎 Also see: Configure an app to access a web API - Microsoft identity platform | Microsoft Learn

✅ Tenant Administrator:  Note that a Nimbus App must be registered at this point.

  1. Go to "API Permissions"
  2. Request new API permission by clicking “Add a permission”. 
  3. Search for "Luware"
  4. Select the entry “Luware Nimbus Login” from your Nimbus App
  5. Select Application Permissions
  6. Select the following role permissions: 
    1. "Provisioning.User.Create" . 
    2. “Provisioning.User.Delete”. 💡Note that this optional. Deletion via API is not supported yet.
  7. Back In API Permissions, click  “Grant Admin Consent for Luware AG” → Green Checkboxes signal the successful permission grant.
Successfully granted API permissions (User.Create and User.Delete)

Authentication 

There are multiple ways to authenticate with your newly created Azure Application. The method of authentication doesn't really matter for Nimbus and depends on your Use Case and external system. We therefore only add some general recommendations and point to the Microsoft Documentation.

Public Client Application

🔎 From: Public client and confidential client applications | Microsoft Learn 

Public client applications run on devices, such as desktop, browserless APIs, mobile or client-side browser apps. They can't be trusted to safely keep application secrets, so they can only access web APIs on behalf of the user. Anytime the source or compiled bytecode of a given app is transmitted anywhere it can be read, disassembled, or otherwise inspected by untrusted parties, it's a public client. As they also only support public client flows and can't hold configuration-time secrets, they can't have client secrets.

🔎 From: Public client and confidential client applications | Microsoft Learn 

After determining the type of client application you're building, you can decide whether to enable the public client flow in your app registration. By default, allow public client flow in your app registration should be disabled unless you or your developer are building a public client application and using the following OAuth authorization protocol or features:

OAuth Authorization protocol/Feature Type of public client application Examples/notes
Native Authentication Microsoft Entra External ID application that requires full customization of the user interface, including design elements, logo placement, and layout, ensuring a consistent and branded look. Note: Native Authentication is only available for app registrations in Microsoft Entra External ID tenants. Learn more here
Device code flow Applications that run on input-constrained devices such as a smart TV, IoT device, or a printer  
Resource owner password credential flow Applications that handles passwords users enter directly, instead of redirecting users to Entra hosted login website and letting Entra handle user password in a secure manner. Microsoft recommends you do not use the ROPC flow. In most scenarios, more secure alternatives, such as the Authorization code flow, are available and recommended.
Windows Integrated Auth Flow Desktop or mobile applications running on Windows or on a machine connected to a Windows domain (Microsoft Entra ID or Microsoft Entra joined) using Windows Integrated Auth Flow instead of Web account manager A desktop or mobile application that should be automatically signed in after the user has signed into the windows PC system with a Microsoft Entra credential
 
 

Confidential Client Application / Client Secret

🔎 From: Quickstart: Register an application with the Microsoft identity platform | Microsoft Learn

Sometimes called an application password, a client secret is a string value your app can use in place of a certificate to identify itself.

Client secrets are considered less secure than certificate credentials. Application developers sometimes use client secrets during local app development because of their ease of use. However, you should use certificate credentials for any of your applications that are running in production.

 
  1. Select your previously registered Nimbus App.
  2. Go to Certificates & secrets > Client secrets > New client secret.
  3. Add a description for your client secret.
  4. Select an expiration for the secret or specify a custom lifetime. 
  5. Click Add.
  6. 🧠 Record the Secret's value for later use within the Nimbus API.
    ☝This secret value is never displayed again after you leave this page.

 From: Public client and confidential client applications | Microsoft Learn 

Confidential client applications run on servers, such as web apps, web API apps, or service/daemon apps. They're considered difficult to access by users or attackers, and therefore can adequately hold configuration-time secrets to assert proof of its identity. The client ID is exposed through the web browser, but the secret is passed only in the back channel and never directly exposed.

 
 

Step 2 - Configure Nimbus

✅Checklist:

🧠 For the next steps in Nimbus you will need the Application ID of your previously registered Nimbus Application.

 
  1. Log into Nimbus Admin Portal.
  2. Go to Tenant Administration  > Provisioning Tenant Settings > “Application Permissions”.
  3. Click on “Add”. 
  4. Fill in the 🧠 Azure Application ID from → Chapter: Step 1 above.
  5. Define the Organization Units scope under which the Nimbus API will have access. 
  6. Save and Close. 
  7. Still within Admin Portal, Go to the Configuration (Admin) > Organization Units
  8. Open your Organization Unit Entry and note the GUID in the browser address bar as follows. 
    🧠 Repeat this step and note down any OU ID you wanna create users in later using the API.
Identifying the Organization Unit IDs for later API usage

Step 3 - Using the API

Now your API should be ready to use and create empty users. 

💡In this example we authenticate using a Confidential Client Application using Client Credentials. Of course you can use any other means of authentication as described in → Chapter: Step 1 > Authentication above.

✅Checklist:

  • 🧠You will need the Nimbus Application ID and the Secret of your App
  • 🧠You also need the Organization Units ID to make API calls
  • ✅ Additionally, you need the O365 IDs of the (future) users you want to provision.
 
  1. Create token using OAuth 2.0. For example, to get a token using Client Credentials, choose the following:
  2. Grant type: Client Credentials
  3. Access token URL: https://login.microsoftonline.com/<tenant id>/oauth2/v2.0/token1
  4. Client ID: 🧠 Application ID of your app
  5. Client Secret: 🧠 As created in your app
  6. Scope: https://portal.{geography}-{number}.luware.cloud/.default2
  7. Client Authentication: Send as Basic Auth header

Footnotes

 1 Head to your Tenant Administration and check the URL in the browser address bar. Look for the part starting with “tenantId=”  tenantId=9fce70af-a632-49ca-bc0d-53db5a21c5b3

2 The Portal URL depends on the geographical location of your Nimbus Cluster. When you log into Nimbus Portal you will be redirected to the right cluster. Check the Access URL list below as a reference.

INC Nimbus Portal URLs

Switzerland 01 https://portal.ch-01.luware.cloud/
Switzerland 02 https://portal.ch-02.luware.cloud/
Germany 01 https://portal.dewe-01.luware.cloud/
Germany 02 https://portal.dewe-02.luware.cloud/
United Kingdom 01 https://portal.ukso-01.luware.cloud/
Australia 01 https://portal.aue-01.luware.cloud/
West Europe 01 https://portal.euwe-01.luware.cloud/
East United States 01 https://portal.use-01.luware.cloud/
Nimbus Portal URLs

✅ Make sure to configure your web proxies to allow access to these domains or whitelist the complete *.luware.cloud domain.

 

POST New Empty User

POST https://admin.{geography}-{number}/api/public-api-next/user

Note

The Admin URL depends on the geographical location of your Nimbus Cluster. When you log into Nimbus Portal you will be redirected to the right cluster. Check the Access URL list below as a reference.

💡Example Connector URL: https://admin.ch-01.luware.cloud/api/public-api-next/user

Note that this URL depends on the Nimbus Cluster where your Tenant is stored. Observe your URL after logging into the Admin Portal.

INC Nimbus Admin URLs

Switzerland 01 https://admin.ch-01.luware.cloud/
Switzerland 02 https://admin.ch-02.luware.cloud/
Germany 01 https://admin.dewe-01.luware.cloud/
Germany 02 https://admin.dewe-02.luware.cloud/
United Kingdom 01 https://admin.ukso-01.luware.cloud/
Australia 01 https://admin.aue-01.luware.cloud/
West Europe 01 https://admin.euwe-01.luware.cloud/
East United States 01 https://admin.use-01.luware.cloud/
Nimbus Admin Panel URL

✅ Make sure to configure your web proxies to allow access to these domains or whitelist the complete *.luware.cloud domain.

 

Body

✅ You require the O365 ID of the user and the 🧠 OrganizationUnit ID from the (permitted) OU (→ Chapter: Step 2 above)

{
 "o365Id": "<guid>",
 "organizationUnitId": "<guid>"
}

Additional API Notes

Notes

Rate Limit: There is a limit of 60 API operations/minute. The API will delay processing if this threshold is exceeded.

 
 
 

Follow-up steps

Granting Permissions

Note that - especially after a first-time Nimbus Installation - Users may need to individually log into Nimbus and grant User Permissions for allowing Nimbus to access their personal details. As a Tenant Administrator you can grant these permissions on behalf of your entire Tenant.

Managing User Details

Depending on the type of service and its configuration, your Users may already receive incoming calls or place outbound calls on behalf of the service. Once you are settled in, head over to the respective User's General User Settings to apply licenses, which enables additional Nimbus Features.

💡 Good to know: You can select multiple Users and manage many of their options at once. Learn more about this by visiting Bulk Editing Users.

 

 

Removing Users

Delete User

☝Note: Nimbus Access and Configuration loss

Deletion of Users has the following effects:
⮑ Access to the Nimbus UI (Portal, Admin) is removed with immediate effect.
⮑ any Nimbus user specific licensing and configuration details are lost. When the user is added later, these configuration details need to be manually restored.

 

Users can be removed from Nimbus by clicking the “Delete Icon”. 

Please note that there are constraints that may prevent you from removing a user. A tooltip over an inactive deletion icon will inform you why deletion is not possible.

Example: A user cannot be removed manually if their user account was provisioned via a service synced to MS-Teams

 

GOOD TO KNOW

  • You can delete any user that has been manually added and is not synched to a MS Teams-based service yet.
  • Users that are automatically (e.g. during Service Provisioning) are tied to an active MS Service team and cannot be deleted. A tooltip will inform about the reasons.
  • Users removed from the Azure user directory are also automatically removed from Nimbus. 
  • Deleting users in the Nimbus UI will not remove them from your O365 / Azure user directory, nor remove them from MS Teams.
 

Editing User Details

To edit a single user, click anywhere on its entry.

 ☝ Please note: 

  • Certain aspects of a user, e.g. Skills and Responsibility Profiles can also be managed by Team Owners, Supervisors or the user themselves via their view of the Frontend UI.  🔍 Also see Agent Service Settings and Duty States.
  • Changes to users can be applied by any (Admin) user with the corresponding role. It is highly recommended for Administrators to coordinate with Team Owners and other Admins when a change of user configurations is planned, as changes can have significant impact on services distributing tasks to that user.

Settings Tabs

🔍 The tabs contents below reflect the user settings available in the Nimbus UI. Please note that some tabs only show when related Nimbus Features were made available on Tenant Level and got enabled via the General tab of the respective user.

General

General User Settings

An example user with all licenses applied
The "General" tab shows details of a user :
Column Description / Purpose
Display Name Display name of the user, as shown in the Nimbus UI.
Organization unit

The Organization Units of this user.

💡 Note: This determines the items the user can see within Nimbus, not necessarily reflecting which services or rights this user has.
First Name First Name - as provided by user directory.
Last Name Last Name - as provided by user directory.
UPN User Principal Name to which calls get forwarded to by Nimbus.
O365 ID Unique Azure / O365 ID under which the user is identified by.
Licenses See chapter below.

USER ACCOUNTS AND USER DETAILS SYNCHRONIZATION

🤔 Why are details read-only? User details are read from your tenant's user directory. Changes are made by your local tenant administrator. Nimbus does not alter these fields to avoid conflicts.

🤔 How are new users added? After Service Provisioning Nimbus adds additional users and grants User Roles accordingly. This " MS Teams-based" User assignment type is the default for Nimbus "Advanced Routing" services. You may however add users manually e.g. to assign them in standalone services that use Skills and Responsibility-based routing without a dedicated Teams channel necessary. More on this topic can be found on Service types.

 

USER SYNCHRONICITY ON DELETED TEAMS

When a MS Teams "Teams" is removed manually - without prior Uninstallation of the related Nimbus service - the users are not shown within the Nimbus user administration list anymore. However, the team and its members are still shown within Service Administration until the Nimbus team is fully removed from Azure. 

Additionally

  • Users may still be shown when part of at least one (still) operational service.
  • Nimbus keeps a history of the team members (retrieved from MS teams channel) even after the channel was removed from the teams client. To the User / Service Administrator this will appear as a mismatch of user count.
 

Licenses

Note that certain Nimbus Features described in the tabs below are tied to a license. You may not see all user options and configuration tabs until a corresponding license is applied to the user.

The following licenses are available:

License Description Enables Features (Tabs)
Contact Center Allows assignment of Skills and Responsibilities for this user to act as Service Agent (either in combination with existing MS-Teams services or standalone). Call distribution to Agents is done via Distribution Policies. 

Skills, Profiles.

🔍 Also see Distribution Order.
Attendant Console Grants access to Attendant Console features for that user, to be found within the Nimbus frontend main menu.

None.

💡 Users can operate Attendant Console immediately via Frontend and adjust their personal Attendant Settings.
Interact Grants access to Interact features, allowing the user direct interaction with customers visiting via a Website or different Frontend.

Interact Tab.

🔍 Also see Interact prerequirements and Use Case - Enabling additional authorization for Interact
Assistant Grants access to Assistant, a standalone app that provides context and open Direct Call Templates during a service call. 

Assistant Tab.

🔍 Also see Assistant Prerequirements, Assistant User Settings, Assistant Configuration
Transcription Grants access to Transcription, enabling live caption and transcription for calls.

None.

💡Users immediately see the Transcription feature widget in My Sessions when enabled and made visible in a widget for their service(s).

✅ Related Requirement: Certain user Nimbus Features also require a service service with the corresponding license applied via Service Administration. For example: Only a Contact Center service can assign Agents manually and enact Distribution Policies.

Modalities

INC Modalities

Modalities are indivdual channels of communication and can be individually enabled or disabled for a user.

Individual modalities enabled / disabled on a user
 

Modality Concepts

For more detailed information, refer to the individual pages on Audio / Video, Instant Messaging, External Tasks and Email, each explaining how they tie into the Task Handling concept behind Nimbus.

 

 

 

 

 
 

Services

Services User Settings

The "Services" tab shows the Nimbus service teams the user is currently a part of:

Column Description / Purpose
Service Display name of the service as shown in the Nimbus UI. Can be changed via the Service Settings.
Users Amount of users in total within that service.
User Assignment Type

Specifies how this user was assigned to a service:

💡 This tab is only for information purposes. The removal of a user is based on the User assignment type of the service.

  • For Microsoft Teams-based services, the user is removed as soon as it also no longer part of the team.
  • For Skill-based (Nimbus) services the user must be manually removed via the Service Administration > Users/Permissions tab.
 
 

Roles

Roles User Settings

The "Roles" tab allows you to inspect and assign (additional or custom) roles to a particular user. It also provides an overview in which Organization Unit scope each individual role applies. 

Roles Tab: Certain roles are automatically synched, while Custom and Nimbus default roles may be manually (re)assigned.

Good to know

  • Tenant Administrators can act outside of the Organization Units restriction and freely can assign Nimbus roles to users.

As Tenant Administrator you are also a regular “Nimbus” user and can also grant yourself (and other admins) access to services. Consult the Change History to follow any changes on roles done by other administrators. 

The Change History will list role changes and the (Admin) user that issued the change.
 

Assigning Default Roles

In this view, Tenant Administrators can do the following: 

  • Inspect the existing roles on a user. Note that some roles are granted automatically (e.g. as part of a MS Teams Ownership) so the "Edit" or "Remove" button may not be shown.
  • Adjust the Organization Units assignment of any existing roles.
  • Apply further default or Custom Roles → Read more on this below. 

Nimbus Default Roles

🔍The tabs below are an excerpt of available Nimbus default Portal Roles and Admin Roles. Consult the User Role (RBAC) Matrix for more detailed information.

Admin Roles

Admin Roles

NOTES

Admin roles described on this page have access to the Nimbus Admin (Backend) Portal.

Show Admin URLs…

Nimbus Admin URLs

Switzerland 01 https://admin.ch-01.luware.cloud/
Switzerland 02 https://admin.ch-02.luware.cloud/
Germany 01 https://admin.dewe-01.luware.cloud/
Germany 02 https://admin.dewe-02.luware.cloud/
United Kingdom 01 https://admin.ukso-01.luware.cloud/
Australia 01 https://admin.aue-01.luware.cloud/
West Europe 01 https://admin.euwe-01.luware.cloud/
East United States 01 https://admin.use-01.luware.cloud/
Nimbus Admin Panel URL

✅ Make sure to configure your web proxies to allow access to these domains or whitelist the complete *.luware.cloud domain.

 
 

✅ Admin roles are granted by Luware Support or selected Service Partners. Details will be discussed during your Onboarding and first Nimbus Installation. 

🔎The table below lists all detail permissions. In a nutshell, Admin user roles can do the following:

Tenant Administrator
  • Can perform all necessary activities to set up services.
  • Has full access to the OData Interface for  historical tracking (except User States tracking) → See Supervisor role .
  • Can perform License Management tasks for both services and users.
  • Can check Operations to monitor and remove (stuck) tasks.
Organization Unit (OU) Administrator
  • Are delegates with similar privileges as the Tenant Administrator. However their scope is limited to the configuration, service and user entities within their Organization Units.
  • Can perform License Management tasks for users.
Workflow (WF) Admin Limited
Admin user roles overview
 

Table: Nimbus Admin Portal Roles and Permissions

🔎Legend: Create, Read, Update, Delete, Execute.

Tenant

Tab Section Property Tenant Admin OU Admin WF Admin limited
General - Name R    
O365 Domain R    
O365 Name R    
Tenant Id R    
Billing Address RU    
Contact - Name RU    
Email RU    
Phone Number RU    
SIP Address RU    
Data Privacy - Allow Partner to see User Identifiers RU    
Allow Partner to see Customer Identifiers RU    
Allow Partner to see Change History RU    
Persist User States in Reporting RU    
Data Retention Time (in Months) R    
Show user Time in State RU    
Allow to share User Identifiers in clear text R    
Provisioning - Default OU for MS Teams creation RU    
Allow service provisioning via MS Teams RU    
Enable Multihoming R    
Default Team Owner Role RU    
Enable Provisioning API R    
Application Permissions CRUD    
Extensions Outbound Directly Invite PSTN for Outbound Calls R    
Directly Invite UPN for Outbound Calls R    
Max Scheduled Outbound Tasks per Service R    
Interact Interact enabled RU    
ACS connection string RU    
O365 UserId RU    
Widget Key RE    
Session Recovery Timeout in Seconds RU    
Authorization RU    
Assistant Use your own ACS instance RU    
Attendant Console Global Contact Search MS Graph Filter RU    
Team Visibility RU    
Presence Tracking Track Presence over Guest Accounts RU    
Grant Permission E    
Primary Account R    
Test UPN (primary) RU    
Secondary Account R    
Test UPN (secondary) RU    
Modalities Audio / Video Leave Nimbus on Blind transfer RU    
Instant Messaging Inactivity Timeout R    
Primary Account R    
Test UPN (primary) RU    
Secondary Account R    
Test UPN (secondary) RU    
Max concurrent IM Tasks per service R    
Use your own ACS instance RU    
ACS connection string RU    
ACS resource ID RU    
Max concurrent External Tasks per Service R    
Email Tasks Max concurrent Email Tasks per Service R    
Licenses - Tenant State R    
Service Advanced R    
Enterprise R    
Contact Center Service R    
Interact R    
User  Attendant Console R    
Contact Center User R    
Interact User R    
Assistant R    
Modalities - Instant Message Modality R    
Modalities - External Task Modality R    
Modalities - Email Modality R    
 
 

Services

Tab Section Property Tenant Admin OU Admin WF Admin Limited
Grid1 UI / View Access Services CRUD CRUD RU
Tasks E E  
Download PowerShell Script E E E
Tasks Tasks List RD RD  
Download Traces E E  
Copy Trace Link      
Settings General Name RU RU R
Service Display Name RU RU R
Service UPN RU RU R
Application ID R R R
Organization Unit RU RU R
PSTN Active RU RU R
PSTN E.164 Number RU RU R
Primary Opening Hours RU RU R
Secondary Opening Hours RU RU R
SLA Hangup RU RU R
SLA Acceptance RU RU R
Short Abandons Threshold in Seconds RU RU R
Hide User Statistics from Reporting RU RU R
Show on Historical Session Page RU RU R
Licenses RU R R
Addons RU R R
Modalities Audio Video checkbox RU RU R
Instant Messaging checkbox RU RU R
External Task checkbox RU RU R
Email checkbox RU RU R
Audio Video - Inbound Conversations toggle RU RU R
Audio Video - Outbound Conversations toggle RU RU R
Audio Video - Audio Video Workflow dropdown RU RU R
Audio Video - Voice Message Channel RU RU R
Instant Messaging - Instant Messaging Workflow dropdown RU RU R
Instant Messaging - Service System Messages RU RU R
External Task - External Task Workflow dropdown RU RU R
Email - Email Workflow dropdown RU RU R
Email - Mailbox dropdown RU RU R
Distribution User Assignment Type RU RU R
Distribution Policy RU RU R
Users Immediately Active RU RU R
Conversation Distribution - Available R RU R
Conversation Distribution - Dnd R RU R
Conversation Distribution - Offline R RU R
Conversation Distribution - Busy RU RU R
Conversation Distribution - Away RU RU R
Task Priority RU RU R
ACW RU RU R
Persistent RONA RU RU R
Auto Redirect in Emergency Case RU RU R
Redirect Destination RU RU R
Extensions Codes - Primary Codes RU RU R
Codes - Secondary Codes RU RU R
Assistant - Assistant Conversation Context RU RU R
Assistant - Service Call Templates RU RU R
Attendant Console - Conversation Context RU RU R
My Sessions - Conversation Context RU RU R
My Sessions - Store Conversation Context Data toggle RU RU R
My Sessions - Keep Context On Transfer - To Service R R R
My Sessions - Keep Context On Transfer - To User RU RU R
My Sessions - Widgets - Codes & Tags toggle RU RU R
My Sessions - Widgets - Embedded Context toggle RU RU R
My Sessions - Widgets - Embedded Context dropdown RU RU R
My Sessions - Widgets - Live Caption toggle RU RU R
My Sessions - Widgets - Transcript toggle RU RU R
My Sessions - Widgets - Session Details toggle RU RU R
My Sessions - Widgets - Map toggle RU RU R
My Sessions - Widgets - Session Parameters RU RU R
Permissions Service Agents List RU RU R
Service Agents Levels and Profiles      
Service Owners List RU RU R
Service Owners Levels and Profiles      
Users Default Team Owner Role RU RU R
Team member can change active state RU RU RU
Users - list R R R
Users - Role - Member R R R
Users - Role - Owner / Limited Team Owner RU RU R
Users - Active toggle RU RU RU
Interact Interact - Active Toggle (general) RU RU R
Interact - Allowed Modalities - Audio&Video Toggle RU RU R
Interact - Allowed Modalities - Instant Message Toggle RU RU R
Interact - Restriction - Restrict Access Toggle RU RU R
Interact - Restriction - Domain Templates Dropdown RU RU R
Interact - Integration RU RU R
Virtual Assistant Virtual User Assistant - Voice Transcription toggle RU RU R
Virtual User Assistant - Live Captioning toggle RU RU R
Virtual User Assistant - Speech Recognizer dropdown RU RU R
 
 

Users

Tab Section Property Tenant Admin OU Admin WF Admin Limited
Users List / View Users CRUD CRUD  
General Display Name R R  
Organization Unit RU RU  
First Name R R  
Last Name R R  
UPN R R  
O365 ID R R  
Licenses RU RU  
Modalities RU RU  
Services Services (user belongs to) R R  
Roles Teams-based roles R R  
Not Teams-based roles RU RU  
Skills Skills and levels RU RU  
Profiles Profiles RU RU  
N/A Reasons Not Available Reasons toggle RU RU  
Not Available Reasons RU RU  
Interact User active RU RU  
Restrict Access R R  
Domain Template R R  
Integration R R  
Assistant Direct Call Templates RU RU  
 
 

Licensing

Tab Section Property Tenant Admin OU Admin WF Admin Limited
Licensing - Tenants Widget      
Tenant State Widget R    
Service Licenses Widget R    
User Licenses Widget R    
Level 1 (Tenants List)      
Level 2 (Licenses List) R    
Edit licences icon E    
Level 3 (Edit Popup) RU    
 
 

Configuration

Group Section Property Tenant Admin OU Admin WF Admin Limited
Tenant Organization Units Organization Units CRUD    
Name RU    
Parent R    
Description RU    
Workflows Resources Resources CRUD CRUD CRUD
Name RU RU RU
Organization Unit RU RU RU
Audio File RU RU RU
Playlists Playlists CRUD CRUD CRUD
Name RU RU RU
Organization Unit RU RU RU
Playlist Entries RU RU RU
Workflows Workflow Instances CRUD CRUD RU
Name RU RU R
Organization Unit RU RU R
Template Type R R R
Workflow Template R R R
Workflow (Editor) RU RU RU
Workflow Templates Workflow Templates CRUD CRUD  
Name RU RU  
Organization Unit RU RU  
Template Type R R  
Workflow Template (Selection) R R  
Workflow Template (Editor) RU RU  
Codes Primary Codes Primary Codes CRUD CRUD  
Name RU RU  
Organization Unit RU RU  
Description RU RU  
Secondary Codes Secondary Codes CRUD CRUD  
Name RU RU  
Organization Unit RU RU  
Description RU RU  
User Not Available Reasons Not Available Reasons CRUD CRUD  
Name RU RU  
Organization Unit RU RU  
Service Conversation Context Conversation Context CRUD CRUD  
Name RU RU  
Organization Unit RU RU  
URL RU RU  
Mailboxes Name CRUD CRUD  
Organization Unit RU RU  
Email Address RU RU  
Parameters Parameters CRUD CRUD  
Name RU RU  
Organization Unit RU RU  
Default Value RU RU  
ID R RU  
Opening Hours Opening Hours CRUD CRUD RU
Name RU RU R
Organization Unit RU RU R
Default RU RU R
Periods CRUD CRUD CRUD
Virtual Assistant Speech Recognizer Speech Recognizer CRUD CRUD  
Name RU RU  
Organization Unit RU RU  
Type RU RU  
Language (MSFT) RU RU  
Region (MSFT) RU RU  
Key RU RU  
Distribution Skills Skills CRUD CRUD  
Name RU RU  
Organization Unit RU RU  
Skill Categories R    
Skill Categories Skill Categories CRUD CRUD  
Name RU RU  
Organization Unit RU RU  
Skill Levels RU RU  
Responsibility Levels RU RU  
Distribution Policies Distribution Policies CRUD CRUD  
Name RU CRUD  
Organization Unit RU CRUD  
Order RU RU  
Preferred User Routing RU RU  
Waiting Time toggle RU RU  
Waiting Time editbox RU RU  
Last User Routing toggle RU RU  
Last User Routing Treshold editbox RU RU  
Distribution Levels RU RU  
Responsibility Profiles Responsibility Profiles CRUD CRUD  
Name RU RU  
Organization Unit RU RU  
Duty toggle R R  
Instant Messaging Direct System Messages Direct System Messages grid1 CRUD CRUD  
General - Name RU RU  
General - Organization Unit RU RU  
General - Description RU RU  
General - User RU RU  
General - Custom Usert Display Name RU RU  
Messages to User - "Acccept" Adaptive Card RU RU  
Messages to User - "Terminate" Adaptive Card RU RU  
Messages to User - Session Embed RU RU  
Messages to Customer - Session Connected RU RU  
Messages to Customer - Session Ended by User RU RU  
Messages to Customer - Session Declined by User RU RU  
Service System Messages Service System Messages grid1 CRUD CRUD  
General - Name RU RU  
General - Organization Unit RU RU  
General - Description RU RU  
General - User RU RU  
General - Custom Usert Display Name RU RU  
Messages to User - "Acccept" Adaptive Card RU RU  
Messages to User - "Terminate" Adaptive Card RU RU  
Messages to User - Session Embed RU RU  
Messages to Customer - Session Connected RU RU  
Messages to Customer - Session Ended by User RU RU  
Attendant Console Address Books Address Books CRUD CRUD  
Name RU RU  
Organization Unit RU CRUD  
Image RU CRUD  
Interact Domain Templates (CORS) Domain Templates (CORS) CRUD CRUD  
Name RU RU  
Organization Unit RU RU  
Domain RU RU  
Nimbus Assistant Direct Call Templates Direct Call Templates CRUD CRUD  
Name RU RU  
Organization Unit RU RU  
Description RU RU  
Trigger Event RU RU  
Call Type R R  
Actions RU RU  
Inbound Internal Teams Calls RU RU  
Inbound PSTN Calls RU RU  
Inbound External Teams Calls RU RU  
Service Call Templates Service Call Templates CRUD CRUD  
Name RU RU  
Organization Unit RU RU  
Description RU RU  
Trigger Event RU RU  
Call Type R R  
Actions RU RU  
Inbound Internal Teams Calls RU RU  
Inbound PSTN Calls RU RU  
Inbound External Teams Calls RU RU  
Outbound Service Calls RU RU  
 
 

Operations

Tab Section Property Tenant Admin OU Admin WF Admin Limited
Service Widgets Tenant dropdown R    
Service dropdown RU    
Tasks doughnut R    
Tasks list RD    
Last Interaction R    
Interactions R    
Last Updated RE    
History R    
Download Traces E    
Copy Trace Link      
Customer Widgets Tenant dropdown R    
Customer dropdown RU    
Last Interaction R    
Interactions R    
History R    
Download Traces E    
Copy Trace Link      
Change History Widgets Tenant dropdown RU    
Last Updated RE    
Change History R    
Details view R    
 
 

1 The term “grid” describes a permission to list (and potentially manipulate) already existing entries of the same type.

 
 

Portal Roles

Portal Roles

NOTES

Roles described on this page have access to the Nimbus (Frontend) Portal.

Show Portal URLs…

Nimbus Portal URLs

Switzerland 01 https://portal.ch-01.luware.cloud/
Switzerland 02 https://portal.ch-02.luware.cloud/
Germany 01 https://portal.dewe-01.luware.cloud/
Germany 02 https://portal.dewe-02.luware.cloud/
United Kingdom 01 https://portal.ukso-01.luware.cloud/
Australia 01 https://portal.aue-01.luware.cloud/
West Europe 01 https://portal.euwe-01.luware.cloud/
East United States 01 https://portal.use-01.luware.cloud/
Nimbus Portal URLs

✅ Make sure to configure your web proxies to allow access to these domains or whitelist the complete *.luware.cloud domain.

 
 

✅  Portal Roles are granted depending on Service type, as Services can be provisioned with different User Assignment Types:

Learn more about User Assignment…

INC User Assignment Types

Each Nimbus service can be of a different user assignment type that determines how users are associated to this service:

  • MS Teams-based: Directly tied to your MS Teams "Teams" as determined during Service Provisioning. Users get automatically added and synced to a Nimbus service.
  • Skill-based: Applies for manually created services via Service Administration. Requires skill-assignment from users you assign to the service from within your tenant directory.
  • None: Has no users, but can be configured by any administrator. Used for IVR or first-level redirection services. 

☝ Important to know: The user assignment type is fixated when a service was either provisioned via MS Teams or manually created via Service Administration, e.g. for IVR or skill-based distribution purposes. A switch between MS Teams-based and Skill-based services is not possible due to how individual users are configured and how Nimbus Features operate.

 

 

 
 

🔎The table below lists all detail permissions. In a nutshell, Portal user roles can do the following:

Tenant Administrator
  • Cannot access service data unless the user is also part of a service.
Organization Unit (OU) Administrator
  • Same as Tenant Admin, however, their scope is limited to the configuration entities (available in Portal) and services within their assigned Organization Units.
Workflow (WF) Admin Limited
User Supervisor(1)

Contact Center Requires a Contact Center license on the user. An addition to an Owner-type role, manually granted via User Administration.
Service Supervisor(1)

Contact Center Requires a Contact Center license on the user. An addition to an Owner-type role, manually granted via User Administration.
Contact Center (CC) User 

Contact Center Requires a Contact Center (CC) license on the General User Settings. 
Service Owner

Contact Center Requires a Contact Center (CC) license on the General User Settings.
Service Agent

Contact Center Requires a Contact Center (CC) license on the General User Settings. An associated Microsoft Teams channel is not required anymore, so the user can act as “standalone” specialist for dedicated tasks.
Team Owner

Default role granted during Service Provisioning via MS Teams.

  • Role synched to MS Teams Channel “Owner” role.(2)
  • Can fully manage the respective Nimbus Service Settings. 
Team Owner Limited

A reduced role that can be granted during Service Provisioning via MS Teams.

  • Manually assigned as “Team Owner Limited” via the Service Settings > “Users” tab.
  • Role synched to MS Teams Channel “Owner” role.(2)
  • Can manage a limited set of Service Settings (SLA, Opening Hours, Resources, Playlists, Workflows).
Team Member

A Nimbus user synched from the Tenant's user directory.

  • Synced with the Team Members of the associated “team” in MS Teams.(2)
  • Can access Nimbus services and data(3) via the Portal and  Nimbus Teams Tab once being a member of a service team.
Portal user roles overview

(1) GDPR General Data Access limitation: If a user has a Supervisor but not a Team Owner / Service Admin role within a service, only limited datasets in the historical BI Template will be shown. Other tabs and queries in the Power BI Report may appear blank. 
☝ This is intended by design. To see a full dataset (including live Reporting data on the portal), the same user also needs a "Service/Team Owner" role assigned for the respective service(s).

(2) Nimbus “Team” roles are only referenced to limit access to Nimbus-related functionality. Vice-versa, MS Teams roles are not affected by Nimbus role assignment. Even in a “limited” Nimbus role - Team Owners can continue to act with all their non-Nimbus related privileges within MS Teams.
(3) ☝Data visibility consideration: Note that MS Teams “Guests” may also get “indirect” access to Nimbus service data, e.g. by seeing call context posted in Adaptive Cards in generally available chat channels. → We recommend to review your MS Teams user privileges regularly to prevent data leaks.

 

Table: Nimbus Frontend Portal Roles and Permissions

🔎Legend: Create, Read, Update, Delete, Execute.

Services Overview

Section Service Supervisor CC User Team Member Service Agent Team / Service Owner Team Owner Limited
Services Overview R   R R R R
Service Settings icon E       E E
Call On Behalf     E E E E
Users - Own Active Toggle   N/A RU N/A RU RU
Users - Active Toggle R N/A R N/A RU RU
Users - Presence icon R   R R R R
Pickup   N/A E N/A E E
 
 

Service Details

Tab Section OU Admin WF Admin Limited Service Supervisor CC User Team Member Service Agent Team / Service Owner Team Owner Limited
Dashboard Dashboard     R   R R R R
Users List     R   R R R R
Users - Own Active Toggle     N/A N/A RU N/A RU RU
Users - Active Toggle     RU N/A R N/A RU RU
Pickup       N/A E N/A E E
Today's Reporting KPIs     R   R R R R
Reporting Service Statistics     R   R R R R
Tasks Heatmap     R   R R R R
Users Statistics     R   R R R R
Historical Sessions Session Results     R       R R
Sessions     R       R R
Session Types     R       R R
Session Directions     R       R R
Historical Sessions - Service Sessions     R       R R
Historical Sessions - User Sessions     R       R R
Session Details Popup     R       R R
Settings General Name RU R R       RU R
Service Display Name RU R R       RU R
Service UPN RU R R       RU R
Application ID R R R       R R
Organization Unit RU R R       RU R
PSTN Active RU R R       RU R
PSTN E.164 Number RU R R       RU R
Primary Opening Hours RU R RU       RU RU
Secondary Opening Hours RU R RU       RU RU
SLA Hangup RU R RU       RU RU
SLA Acceptance RU R RU       RU RU
Short Abandons Threshold in Seconds RU R RU       RU RU
Show on Historical Session Page RU R R       R R
Hide User Statistics from Reporting RU R R       R R
Show on Historical Sessions Page RU R R       R R
Modalities Audio Video checkbox RU R R       RU R
Instant Messaging checkbox RU R R       RU R
External Task checkbox RU R R       RU R
Email checkbox RU R R       RU R
Audio Video - Inbound Conversations toggle RU R R       RU R
Audio Video - Outbound Conversations toggle RU R R       RU R
Audio Video - Audio Video Workflow dropdown RU R R       RU R
Audio Video - Voice Message Channel RU R R       RU R
Instant Messaging - Instant Messaging Workflow dropdown RU R R       RU R
External Task - External Task Workflow dropdown RU R R       RU R
Email - Email Workflow dropdown RU R R       RU R
Email - Mailbox dropdown RU R R       RU R
Distribution User Assignment Type RU R R       RU R
Distribution Policy RU R R       RU R
Users Immediately Active RU R R       RU R
Conversation Distribution - Available R R R       R R
Conversation Distribution - Dnd R R R       R R
Conversation Distribution - Offline R R R       R R
Conversation Distribution - Busy RU R R       RU R
Conversation Distribution - Away RU R R       RU R
Task Priority RU R R       RU R
ACW RU R R       RU R
Auto Redirect in Emergency Case RU R R       R R
Redirect Destination RU R R       R R
RONA RU R R       RU R
Extensions Codes - Primary Codes RU R R       RU R
Codes - Secondary Codes RU R R       RU R
Assistant - Assistant Conversation Context RU R R       RU R
Assistant - Service Call Templates RU R R       RU R
Attendant Console - Conversation Context RU R R       RU R
My Sessions - Conversation Context RU R R       RU R
My Sessions - Store Conversation Context Data toggle RU R R       RU R
My Sessions - Keep Context On Transfer - To Service RU R R       R R
My Sessions - Keep Context On Transfer - To User RU R R       RU RU
My Sessions - Widgets - Codes & Tags toggle RU R R       RU R
My Sessions - Widgets - Embedded Context toggle RU R R       RU R
My Sessions - Widgets - Embedded Context dropdown RU R R       RU R
My Sessions - Widgets - Live Caption toggle RU R R       RU R
My Sessions - Widgets - Transcript toggle RU R R       RU R
My Sessions - Widgets - Session Details toggle RU R R       RU R
My Sessions - Widgets - Map toggle RU R R       RU R
My Sessions - Widgets - Session Parameters RU R R       RU R
Agents Service Agents List R R R       R R
Service Agents Levels and Profiles RU           RU  
Service Owners List R R R       R R
Service Owners Levels and Profiles RU           RU  
Users Default Team Owner Role RU R         R R
Team member can change active state RU RU         RU R
Users - list R R         R R
Users - Role - Member R R         R R
Users - Role - Owner / Limited Team Owner RU R         R R
Active toggle RU RU         RU RU
 
 

Configuration

Tab Section OU Admin WF Admin User Supervisor Team / Service Owner Team Owner Limited
Workflows Resources Resources grid1 CRUD CRUD   CRUD CRUD
Name RU RU   RU RU
Organization Unit RU RU   R R
Audio File RU RU   RU RU
Playlists Play List grid1 CRUD CRUD   CRUD CRUD
Name RU RU   RU RU
Organization Unit RU RU   R R
Play List RU RU   RU RU
Workflows Workflow grid1 CRUD RU   CRUD CRUD
Name RU R   RU RU
Organization Unit RU R   R R
Template Type R R   R R
Workflow Template R R   R R
Workflow RU RU   RU RU
Codes Primary Codes Primary Codes grid1 CRUD     CRUD  
Name RU     RU  
Organization Unit RU     R  
Description RU     RU  
Secondary Codes Secondary Codes grid1 CRUD     CRUD  
Name RU     RU  
Organization Unit RU     R  
Description RU     RU  
Service Conversation Context Conversation Context grid1 CRUD     CRUD  
Name RU     RU  
Organization Unit RU     R  
URL RU     RU  
Parameters Parameters grid1 CRUD     CRUD  
Name RU     RU  
Organization Unit RU     R  
Default Value RU     RU  
ID RU     R  
Opening Hours Opening Hours grid1 CRUD RU CRUD CRUD CRUD
Name RU R RU RU RU
Organization Unit RU R RU R R
Default RU R RU RU RU
Periods CRUD CRUD CRUD CRUD CRUD
 
 

Flexible Dashboards

Contact Center - Non-Personal Dashboards and Personal Dashboards require a Contact Center license on the user to become accessible. Each Dashboard can be customized with Dashboard Widgets.

🔎 W = Widget access. A user needs a Contact Center license to see Dashboards, and can add Dashboard Widgets. However, seeing data (Services / Users / OUs) inside those widgets requires an additional R permission (e.g. Team Member, Agent role) within the service / team.

 
Tab Section   User Supervisor Service Supervisor CC User Team Member Service Agent Team / Service Owner Team Owner Limited
Dashboards Personal Dashboards     CRUD        
Non-Personal Dashboards     R        
Dashboard Widgets Service Service KPI Tile   R W R R R  
Service KPI Tabular   R W R R R  
Service KPI Chart   R W R R R  
Service KPI Comparison Chart   R W R R R  
Service KPI Graph   R W R R R  
Service Queue Tabular   R W R R R  
Live Service Tasks Tabular   R W R R R  
Service Outbound Tasks Tabular   RE W R R RE  
Service External Tasks Tabular   RE W R R RE  
Service Heatmap   R W R R R  
Service Supervision   WRE W        
User User Performance Tabular R   W        
User State Tabular R   W     R  
User Supervisor Tabular RE   W        
User State Chart R   W     R  
User Tile R   W     R  
Common Markdown     WR        
Date & Time     WR        
Embedded Website     WR        
 
 

1 Note: The term “grid” describes a permission to list (and potentially manipulate) already existing entries of the same type.

 
 

Assigning Custom Roles

In addition to the Nimbus predefined User Roles (Team Member, Team Owner, etc.), you can also assign Custom Roles to Nimbus users. Users with Custom Roles assigned can access Nimbus pages and properties according to the permissions defined in the Custom Role.

Custom Roles appear in the dropdown list among other User Roles when you click on Add. Once a Custom Role is assigned to a user, you can assign Organization Units to it just as for other User Roles.

💡 Note that you can assign up to 5 Custom Roles to a user. If this limit is reached for a user, further Custom Roles will be disabled in the dropdown.

Expand to learn more about Custom Roles…

Custom Roles

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.

Contact Center Custom Roles configuration entries can be defined with no restriction. Applying a role however requires a Contact Center user license on the user, which enables the Roles Tab in the User Settings. The License itself is applied in the General 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. 

  • Roles are assigned via User Administration > <User Name> >  Roles Tab.
  • As long as at least one user has a role assigned, deletion of the role is not possible.

💡 Note that you can assign up to 5 Custom Roles to a user.

Creating a Custom Role

Custom roles are defined in several tabs:

  • General Tab - Setting the (or changing an existing) display name, Organization Unit placement.
  • Administration Tab - Setting detail permissions for the (new) role.

General Tab

General Tab

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 Tab 

Administration Tab

Here you can grant individual Read, Update, Create, and Delete rights to the role. While selecting individual permissions, please note the following behavior:

  • Note that 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 table:

1st Level (Entity) Area / UI Tab Setting Section What the setting affects & related KB links

Services

 Service Administration and related Service Settings.
  Service   Viewing the grid of available services, e.g. within the Service Administration.
  General   General Service Settings tab.
    General info Clear / Service Name, PSTN configuration.
    Opening Hours Opening Hours setting application.
    Reporting Nimbus Reporting SLA Settings.
    Licenses and Addons Applying License Management. Also see Nimbus Features.
  Modalities 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 Email  settings, Mailboxes, and Workflows.
  Distribution Distribution Service Settings.
    Users User Assignment Type and New User default active setting.
    Conversations Distribution Distribution Service Settings, Task distribution based on MS Teams status.
    Task Priority Task Priority setting for the service.
    ACW After-Call Work toggle, timings, extensions, timeouts.
    RONA RONA settings, reset times.
    Emergency Routing Emergency routing / redirection settings.
  Extensions Extensions Service Settings.
    Codes Codes assignment.
    Assistant Conversation Context and Service Templates.
    My Sessions My Sessions widgets, Conversation Context, Context data storage, Custom Context Parameters on transfer (to service, to user)
  Interact   Interact Service Settings. Modalities, Interact Domain Templates (CORS).
  Users (User Assignment Type: MS Teams based) → see Service Permissions.
    Default Team Owner Role Users Service Settings, Default Team Owner role, 
    Team member can change active state Allow self-toggle for “Active” service participation. → see User States.
    Users list List of roles and Active State toggles.
  Permissions (User Assignment Type: Skill-based)  → see Service Permissions.
    Service Agents and Owners Manually assigned “Agent” → see Portal Roles for detail permissions.
     Service Owners Manually assigned “Service Owner” → see Portal Roles for detail permissions.
  Virtual Assistants Virtual Assistants Service Settings 
     Virtual User Assistant Speech Recognizers, Transcription and Live Captioning Settings. 
 
 

Learning more about about roles

The roles you assign here use the existing Role-based Access Concept (RBAC) in Nimbus. 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.

 
 
 
 
 

Skills

Skills User Settings

Allows assignment of previously configured skills to this user.

Preconditions

  • The "Skills" tab is only available when the user has a Contact Center license assigned in the "General" Tab.
  • Skills and Categories need to be defined first (via Admin > Configuration) before you can assign them. Refer to Skills and Responsibilities.
 

Once Preconditions are met, it's time to assign skills via the "Skills" tab. Perform the following steps:

  1. First, add a Add a language skill to the user. In this example we use Greek and English, both in the the category "Language Proficiency". 
    ⮑ 💡Note how Skill Levels were originally enabled for this category and thus need to be defined once the skill is added to a user.
Assigning Skills and Responsibilities to a user, here with newly created profile called “Backoffice”
  1. Use the Sliders to define the Skill levels
    1. 💡Note that skills with levels are always including previous stages. An Advanced user will also be considered as Beginner.
    2. You can require / exclude users when configuring your Distribution Profiles (e.g. to start support with "Native Speakers" first and gradually lowering the skill requirements). ☝ This is a very good point to double-check if your skills / categories / levels within the complete and in order. Once assigned to users they cannot be changed easily their levels are now being fixated.
  2. Use Responsibilities as optional level
    1. 💡This means that you can define OPTIONALLY responsibility criteria in addition to existing skills level.
  3. Continue to define levels and responsibility for each profile. 
    1. 💡 Note that a user can have multiple Responsibility Profiles assigned, each with their own set / level of skills and responsibility.
    2. 💡You can add further profiles to a user via the Profiles tab.

Important: Levels and Distribution Policies

Distribution Policies define the skill requirements to your users. If your user does not fullfill the level criteria or lacks any of the skills, they will not be selected for calls.

Related to that: Note that responsibility - while optional on the user definition - will exclude the user from any Distribution Policies that define / demand levels of responsibility. Learn more about this on our Distribution Order page.

 

Skills assigned to a user will have no effect on call distribution until you perform the following related configuration steps:

  1. Don't forget to include newly required skills and responsibilties in your Distribution Policies. They will define the call escalation levels on your available user pool.
  2. Assign the Distribution Policy to the corresponding  Contact Center licensed Service. This is done in the individual Service Settings > "Distribution" tab. Note that this only works on services where the User assignment type is "Skill-based".
Assignment of a previously defined Distribution Policy
 

 

 
 

Profiles

Allows assignment of previously configured profiles to this user. 🔍 Learn more about this on: Responsibility Profiles.

PREREQUISITES

  • The "Profiles" tab is only available when the user has a Contact Center license assigned in the "General" Tab.
  • A profile relies on multiple User Skills and Responsibility Levels to be defined first.
 
 
 

N/A Reasons

Allows to assign Not Available Reasons to a user. 

PREREQUISITES

  • The "N/A Reasons" tab is only available when the user has a Contact Center license assigned in the "General" Tab.
  • Reasons are defined in the Configuration as described on the Not Available Reasons page.

🔍 Reasons are selected by users within Assistant upon entering a "Not available" User State .

 
 
 

Interact

Interact User Settings

Preconditions

  • Interact is enabled on tenant level. If this is not the case, ask your Admin or Luware Support to do this for you.
  • To set up Interact for the first time Use Case - Setting up Interact needs to be completed. This allows customers to reach a user directly from external URLs (websites) via small chat or voice widgets.
  • A Contact Center license needs to be assigned to the user to enable the Interact tab.
 

Editing Interact User Details

After the user has been granted a license, the Interact tab is visible and the option can be enabled.

The following elements can be configured:

Element  Description
Active

✅ This feature needs to be enabled for your Tenant, see preconditions above.

☝ Note that Interact licenses (granted via General Tab) remain assigned to this user even when this is toggled inactive.
Audio & Video

When enabled the user can be contacted via call modality using Interact. The Call Handling procedure is the same as regular Nimbus service calls.

💡Regular Nimbus distributed service calls will still reach this user despite of this setting.
Instant Messaging

When enabled the user can be contacted via chat modality using Interact. The Chat Handling procedure is the same as regular service chats.

💡Regular Nimbus distributed service chats will still reach this user despite of this setting.
Direct System Messages

Direct system messages configured in Admin > Configuration > Instant Messaging can be applied here.

💡These messages customize how this user name appears in chat and which custom messages are sent to that user and the customer they interact with.
Restrict Access

✅You need to configure at least one Interact Domain Templates (CORS)  for this option to be come available.

 

💡Domain templates act as whitelists:

  • When enabled, web page access to this user is limited to domains specified in the CORS templates. 
  • When disabled. any web page may contact the user via the snippet.
Domain Template Lists configured Interact Domain Templates (CORS)  available under the same  Organization Unit  as the current user.
User Snippet

Default script with settings of  current  user, which is later can be inserted into a the web page and used as a contact widget.

 

👆 Please note that the Contact ID and WidgetKey are unique to the current user and should not be mixed up.

 

💡 For easy Snippet Code retrieval use the Copy button.

✅ To test contacting this user, use the use the preview link.
 
 

Assistant

Assistant User Settings

Preconditions

The Assistant license needs to assigned to a user for the settings to become visible. → See General User Settings. If you want to assign Assistant licenses in Bulk, head over to License Management.

Granting the Assistant license will make the tab visible.
 

Assistant Context and Templates

Allows to assign Direct Call Templates to the user. Template actions trigger only on direct calls to this user in particular.

Element

 Description
Direct Call Templates

✅ Requires one or several configured Direct Call Templates to assign.

By clicking "+Add", template items under the same Organization Units (or higher) can be assigned to this user.

💡 Note that the templates will be called in the order they were added to the list. You can drag and drop template items to change the order.

🤔 Can I also assign Templates to Services?

Yes Service Call Templates are similar in design to Direct Call templates, but are configured separatedly and applied on service level.

Show me how to assign templates to a service

To assign templates that trigger on service call:

  1. You need define separate Service Call Templates first.
  2. Assign these service templates via the Service Settings > Context tab. → They will now trigger on a service call, in addition to any individual user templates.
 
 

🤔 What is Conversation Context and how is it different to Templates?

  • Conversation Context can be seen as "common ground" URLs to be opened for all service users within the Nimbus portal or Assistant. Context is applied via Extension Service Settings.
  • Compared to Context, Call Templates allow for more control and can also execute sequential actions in the background, invisible to users (e.g. to perform a ticket-creation while triggering a status update).
  • Context has no functional reliance or dependency to either service or direct call templates. Both features can be used in combination or standalone. ☝ However, be aware that your users might get duplicate websites opened when they are defined as context / templates and assigned on both service and user level.
 
 
Skills and Responsibilities

By defining and assigning various skills and responsibility to Contact Center use...

User Assignment Types

INC User Assignment Types Each Nimbus service can be of a different user assignme...

Service Administration

The " Services" view allows administrators to manage, edit and remove existing te...

Tenant Administration

The Nimbus Tenant view allows to assign security groups, change tenant details an...

Table of Contents