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.

Ā 

Ā 

Table of Contents