Tenant Administration

The Nimbus Tenant view allows to assign security groups, change tenant details and configure various Nimbus Features and extension apps. 

VIEW DIFFERENCES

The Tenant administration and related tabs may look different for single- and multi-tenant admins. 

Access to configuration elements is determined by the Nimbus Role Access Concept. For instance, single tenant admin permissions may restrict you to only edit non-technical information such as: Company Name / Division, Billing Address, Technical Contact


💡 Note: Depending on Admin Roles detail permissions, certain fields described below may not be shown or protected against change. If you need to change restricted fields or have questions, get in touch with with your support partner or - in case of further issues - Luware customer support.

Luware Support Address

 Luware Website https://luware.com/support/
Luware Helpdesk https://helpdesk.luware.cloud 
Cloud Service Status https://status.luware.cloud/
Luware support contact details
 

Access Tenant details

  • Multi-tenant administrator you can use the Edit button for each tenant to access and change details.
  • Single-Tenant administrators will not see a selection and get right into the Tenant Configuration, showing various tabs.
In a multi-tenant view you can click “Edit” to get to the individual Settings of that Tenant

 

Tenant Settings Tabs

Saving changes in multiple tabs

Clicking SAVE affects changes in all tabs. For that reason, warning icons in the tabs will indicate when there is missing or wrong information that prevents saving. 

Before saving, review the marked tabs first
 

General

Here you can change and enter details on your tenant, change or access the billing address and / or technical contacts. 

General Tenant Settings

Section Option / Element Description
Tenant Information Name Name as displayed in the tenant list
O365 Domain The first or sub-level domain that the tenant is under.
Tenant ID The tenant ID of the group as defined in Microsoft Azure Portal.
Company Name Clear name field for the Company behind that tenant.
Partner Administration Security Group (GUID)

Azure Security Group GUID for which corresponds to the " Partner Admin of a Tenant " permission set. In most scenarios this group will usually have access to some tenants under that partner domain.

🔍 See info below for details

Tenant Administration Security Group (GUID)

Azure Security Group GUID for which corresponds to the " Tenant Admin " permission set. In most scenarios this group will usually have access to one tenants under that partner domain.

🔍 See info below for details

ABOUT SECURITY GROUP PERMISSIONS

If fields are greyed-out they are managed by a higher permission level. Refer to Roles and Permissions for details.

💡 You can retrieve the Security Group GUID from Microsoft Azure Portal > Groups > <Your Security Group Name> > Overview > Object ID

💡 Upon entering the ID Nimbus will check if permissions and if the ID is valid. If so, the "Details" button for the security group becomes enabled and you can inspect the group members.Helpjuice Info Callout Title

Helpjuice Info Callout Body

 

 

CRM ID ID for your Customer Relationship Management tool.
Billing Address

Billing Address

  • Street Address 1 & 2
  • Zip Code
  • City
  • Country

Address of the partner to which the bill for this tenant should be sent to.

💡 Note that the country / address is just for billing purposes and does not reflect or change the Nimbus tenant data storage location.

 
 

Contact

Here you can specify a technical contact to notify in case of maintenance, issues and for other technical questions:

Contact Tenant Settings

Contact Details

Technical Contact for this tenant

  • Name
  • Email
  • Phone Number, E 164 Format
  • SIP Address

Partner

 

🔍 This section is restricted to Luware and Partner administrators. 

Assigns a Partner to this tenant.

Visit our website to learn more about the → Luware Partner program.

 
 

Data Privacy

Data Privacy Tenant Settings

In this tab you can configure user-related data privacy settings

On Data Privacy Settings and restrictions

Certain Settings in this section may be visible/restricted to Luware and Partner administrators as defined per User Role (RBAC) Matrix

If you need to change Data Privacy settings described on this tab but are unable to do so, consult with your support partner or Luware directly.

Luware Support Address

 Luware Website https://luware.com/support/
Luware Helpdesk https://helpdesk.luware.cloud 
Cloud Service Status https://status.luware.cloud/
Luware support contact details
 
Option / Element Description
Allow Partner to see User Identifiers

Determines if the partner is able to see Nimbus user (team member) clear names.

  • When enabled, the full user names are shown.
  • When disabled, Nimbus users will be shown anonymized with asterisk * placeholders.
Allow Partner to see Customer Identifiers

Determines if the partner is able to see Nimbus calling customer identifiers.

  • When enabled, the full customer identifiers are shown.
  • When disabled, Nimbus calling customers will be shown anonymized with asterisk * placeholders.
Persist User States in Reporting

Contact Center This feature can be enabled Tenant-wide, but mainly makes use of Contact Center service features for reporting.

With this feature active, User States are tracked and added as part of the Nimbus Reporting Model , and exposed via the Nimbus OData interface.

  • When enabled, data becomes visible in Power BI reports (User State Tab). ✅ You require a "User Supervisor" role to query these extended user details.
  • When disabled, existing User Presence State reports will be closed and no further entries are generated. 💡 Already existing data is not affected by this.

🤔 When to enable this? Tracking presence states can generate considerable amounts of personal user data. Aside from Power BI query performance considerations on a large userbase you need to consider privacy and EU GDPR compliance before enabling this feature.

🤔 What data is being tracked? User, User ID, Organization UnitResponsibility Profiles (User State), MS Teams Presence Status and all related event changes with timestamps and durations.

 Click to learn more about User States ...
Show user "Time in State"
  • When enabledUser State times are tracked and shown as "Time in State" within the Nimbus UI (e.g. in customizable and service Personal Dashboards, Widgets, etc.). The List of Services within the Service Administration also shows this column.
  • When disabled, the "Time in State" columns will not be shown in either Portal UI.

 

 
 

Provisioning

Tenant Provisioning Settings

Here you can configures the Service Provisioning default settings which apply when new Nimbus services are created.

Default OU for MS Teams creation

Sets the default Organization Unit (OU) for new services during their first provisioning.

🔍 Please Note:

  • During Service Provisioning users can still change the default to any provided "sub" level OU during installation. The OU can also be changed later in General Service Settings of that service. 
  • When the OU gets deleted, the OU default selection is moved one level higher (up to root). 
  • If either user or service are completely new in Nimbus – or the OU cannot be selected for other reasons – both the user and service are placed in a "Default Organization Unit for Microsoft Teams-based teams". Both can be moved to other Organization Units via the User Administration and Service Administration respectively.
Allow service provisioning via MS Teams

Set the minimum roles required to Provision a new Nimbus team directly from the MS-Teams UI.

Settings are: 

  • Everyone (default)
  • Tenant & Organization Unit Administrators
  • Tenant Administrators
  • No one → provisioning disabled on MS Teams side

💡 This setting does not prevent users from installing the Nimbus Personal App.

🔍 Non MS-Teams synched Service types can still be provisioned via the backend by any administrator, regardless of the setting made here.

Users without the permission to Provision new services may still remove the Nimbus tab from MS Teams (as Nimbus cannot impact or restrict the default MS Teams interface). However, they can not trigger a removal of the service itself and its data and the Nimbus tab can be re-added.

Default Team Owner Role

The default role assigned to a new user when a new Nimbus team is provisioned directly from the MS-Teams UI. Options are: 

  • Team Owner (Default) with full team settings and configuration rights.
  • Team Owner Limited (a Nimbus specific role with a reduced set of User Roles).

💡 Existing services are not affected by this change and changing this setting will only affect future services provisioned via MS Teams

 
 

Extensions

Tenant Extension Settings

🔍 Here you can configure all additional Nimbus extensions and separately enabled Nimbus Features.

💡 Note that certain extensions may be configured but will not take effect until the licenses for your users (User Administration) and services (Service Administration) are applied.

Outbound

Option / Element Description
Max Scheduled Outbound Tasks per service

Limits the maximum outbound tasks per service that can be simultaneously scheduled / in progress

Default 20 / Min 1 / Max 50

 

🔍 Note: Outbound Tasks – same as inbound tasks – are distributed among available Nimbus users and shown in the Personal Dashboards > in the "Service Outbound Tasks Tabular" widget. Tasks are scheduled using the Microsoft Power Automate Connector > Flow Actions. Once the limit is reached, a flow error is returned and the task will be discarded.

Interact

Configures options for Interact, an optional feature of Nimbus. If you want to learn more head over to our Luware Solutions page.

Option / Element Description
Interact enabled

The global setting which activates Interact for Nimbus

  • When enabled, the calls in Interact will reach an agent in Teams.
  • When disabled, the calls in Interact will not reach an agent, even if the tenant is configured for Interact calls.

🔍 Enabling this requires you to fill in an ACS connection string. Refer to our Use Case - Setting up Interact which explains setup steps in detail.

ACS connection string

Connection string for Azure Communication Services. Required to use Interact

🔍 Learn how to generate this string via the Microsoft Documentation .

✅ "Check"- performs a check if it's possible to create a token for the user using this string. If the connection fails (with a correct string) it most likely means there are insufficient permissions.

O365 UserID ID of the user on behalf of whom meetings on the backend will be created.
Widget Key

Random guide generated for the Tenant. The key is sent with each request to the backend and checks the validity of the widget, depending on which it either allows or rejects the request for the backend.

  • "Copy" - copies the guide value for (future) use in a web client.
  • "Refresh" - updates the guide with a new one.
Session recovery timeout in seconds

Time in seconds before a closed session is ended permanently. 

Default: 20; Min: 5; Max: 60.

KNOWN ISSUE Currently the timeout behavior is different between a direct (to Agent) conversation and a Service-distributed conversation:

  • On a direct conversation: A session timeout starts when the customer leaves the conversation. When an agents leaves an ongoing conversation, they are re-invited if the customer rejoins within the timelimit.
  • On a service conversation: The session is only restored when the agent remains in the conversation. When the agent leaves, a new session is started (including a complete re-execution of the IM workflow).
Authorization

Determine if a session requires further authentication:

  • None (default) - when set, the token is not verified. 
  • Verify Token - when set, verifies the validity of the token. The error will occur if the token is expired or invalid.
  • Verify Token & Tenant - when set, verifies the validity of the token and that it belongs to a certain tenant.

Learn how to set up authorization...

Use Case - Enabling additional authorization for Interact

In this use case, we're going to describe how you can set up an access token to be used for Interact.

🔍 This use case is optional in case you want to verify user access additionally via tokens in your Tenant Administration > Interact settings.

Steps below refer directly on the Daemon application MSFT help article and the subchapters. 

 

Create an Azure Application

  • Add a new app under app registrations in the Azure Portal
  • Preferably a single tenant application
  • No reply-URL needed for the client-credential flow (standard OAuth 2.0 client credentials grant)

🔍 Refer to: https://docs.microsoft.com/en-us/azure/active-directory/develop/scenario-daemon-app-registration

Generate Secret/Certificate

  • Generate a secret or certificate which will be used as the applications credentials

🔍 From https://docs.microsoft.com/en-us/azure/active-directory/develop/scenario-daemon-app-registration

To add credentials to your confidential client application's app registration, follow the steps in Quickstart: Register an application with the Microsoft identity platform for the type of credential you want to add:

Create own Daemon App with .NET/Java/Node/Python

  • Based on the language instantiate the confidential client application with the client secret or the certificate

🔍 Refer to the table on https://docs.microsoft.com/en-us/azure/active-directory/develop/scenario-daemon-app-configuration?tabs=dotnet

Acquire a token and pass it to the SDK

  • Based on the language instantiate the confidential client application with the client secret or the certificate

🔍 Refer to: https://docs.microsoft.com/en-us/azure/active-directory/develop/scenario-daemon-acquire-token?tabs=dotnet

 
 

Assistant

Configures options for Assistant, an optional feature of Nimbus.

Option / Element Description
Use your own ACS Instance

Toggle. Enable when you have your own Azure Communication Services instance.

🔍 Enabling this requires you to fill in an ACS connection string. Refer to Use Case - Setting up Assistant which explains the setup steps in detail.

ACS connection string

Connection string for Azure Communication Services. Required to use Assistant with your own ACS instance.

🔍 Learn how to generate this string via the Microsoft Documentation .

💡 Once a string is entered a "Check" option verifies if it's possible to create a token for the user using this string. If the connection fails (with a correct string) it most likely means there are insufficient permissions.

Attendant Console

Allows to configure an MS Graph Filter that automatically limits the search used in Attendant Console

Option / Element Description
Global Contact Search MS Graph Filter

Uses the MS Graph REST API to filter1 users according to your tenant admin account permissions. This filter will be applied to the O365 like Attendant Console to provide internal Nimbus users a narrowed-down pool of search results. 💡 By default this filter (textbox) is empty, allowing users to perform a search on your entire tenant.

 See: https://docs.microsoft.com/en-us/graph/api/overview


☝ Please note that this field requires only parameters for the "filter" field of a MS graph query, not the whole API request URL. Keep this in mind when using MS Graph Explorer to test, copy & paste your updated filter parameters.

💡 End-users will not see this filter in the frontend UI, but will have search results narrowed down accordingly.

🔍 Refer to our Use Case - Filtering Attendant contact search via MS Graph.


Example filter for users within domain and preferred language:

endsWith(userPrincipalName,'onmicrosoft.com') and preferredLanguage eq 'en-GB'
 

NOTES AND KNOWN LIMITATIONS

KNOWN LIMITATION The filter will be applied to all O365 accounts, including those of Nimbus Services! Overly strict filters may limit the Nimbus users' capability to forward calls via search.


  • This text field does not perform validity checks for correct syntax. → Please refer to the official MS Graph REST API documentation for details.
  • Nimbus combines both visible and backend filters with an 'AND' clause. When a frontend user (e.g. via Attendant Console) searches within the same fields as defined in your query there can be a clash. 
  • Depending on the field(s), on which the filter is applied, additional permissions might be required for Nimbus to make a query on your behalf. Without these permissions, search functions in Attendant Console might not work at all.
  • If the filter query is broken for any reason (e.g. missing permissions, typos, syntax) the search in any Frontend may not show any results at all.
 
Team Visibility in Attendant Console

The Attendant Console search allows to forward calls to Nimbus teams and services. To avoid bypassing queues of services, the visibility of team members can be hidden.

  • Do not show any members - Only limits the search to Nimbus services and their overall availability. No individual team members are shown.
  • Shown own members - will only show available team members of Nimbus services that the Attendant user themself is a part of.
  • Show all members - will show the availability of all team members of any Nimbus service.

Presence Tracking

"Presence Tracking" allows Nimbus to make smarter routing decisions by determining if your users are already in a Teams call (non-Nimbus). Please note that a few steps are required on your Microsoft Tenant for this feature to work. Read the instructions below carefully and contact Support in case you need assistance. 

Track Presence over Guest Accounts

Allows you to use two Luware-provided guest accounts which enable Nimbus to poll the extended presence status on all users within your Tenant.

🔍 Also see related Microsoft Documentation: User Presence States in Teams .

☝ If you want to keep using "Presence Privacy mode" on your Tenant you need these guest account. Otherwise Nimbus cannot route anything.

🤔 Why is this necessary?

Without a guest presence account, Nimbus can only retrieve a simplified presence status such as "Busy" "Away" or "Available" for your users. For extended status presence such as " Busy → In a Call " or " Busy → In a Conference " these presence accounts are required to improve call routing. When activating the presence tracking feature, call handling is handled according to the MS Teams status as follows:

Calls are delivered while Calls are NOT delivered while

Available

Busy*

Busy in a Meeting*

  • Away*
  • Busy in a call
  • in DND (Do Not Disturb)
  • Offline

*Only when Distribution Service Settings are set accordingly within the individual Service.

With extended presence enabled, Nimbus can now distinguish a "Busy" status and plan/avoid call distribution accordingly.

KNOWN LIMITATION For "Away" and "BRB" states the "In a Call" extended status is not returned by Microsoft. W hen any of these status were manually set by users, Nimbus doesn't have additional information whether or the user is already in a call and will follow the plain "Away" status as defined in Distribution Service Settings to route the calls. → As this is a Microsoft-limitation we cannot provide a fix or workaround for this at the moment.

Grant Permission (Copy to Clipboard)
✅ An auto-generated link that you (as Tenant Admin) need to paste into your browser. → Grants the delegated permissions listed below to the Nimbus App. The Azure guest accounts use these to read presence on all users on your tenant.
💡 You can do this step regardless of the Presence Account 1&2 field contents. The permissions will remain even if the guest users change.
Extended permissions are:
  • Presence.Read.All
  • User.Read
  • User.ReadBasic.All

🤔 What are these Permissions used for? Nimbus uses these extended permissions to enable presence-based features, primarily for targeted call distribution and updating availability in the frontend UI. Also read → Track Presence over Guest Accounts above.

✅ To test these permissions y ou need to invite at least one presence account. → See "Presence Account 1&2" and → "Test UPN" below for further details.

Presence Account 1&2

Used for extended presence status tracking on your tenant. Account 2 acts as (temporary) fallback when account 1 does not work for any reason.

🔍 These guest accounts require extended permissions → see "Grant Permission" above.

Click here to learn how to set up Presence Accounts

Use Case - Tracking extended user presence via Azure guest accounts

In this use case, we explain how to track extended user presence. For this you need to invite Nimbus Guest Users to your tenant.

PRECONDITIONS

  • Nimbus Installation is complete and at least one Service is provisioned on your tenant.
  • In extension you should know about the Distribution Service Settings, accessible to you if you are Team Owner or Tenant Admin. 💡 These settings define when service calls are distributed to the users (team members) based on their MS Teams status (Away, DND, etc). More on this will explained below.
  • You require Tenant Administrators rights to access the Nimbus Tenant Administration > "Presence Tracking" section.
    • You also need Tenant Admin credentials to invite guest users within your Azure Portal.
 

🤔 What is extended user presence and why guest accounts?

For an extended status presence such as "Busy → In a Call" or "Busy → In a Conference", these presence accounts are required to improve call routing. Without having guest users on your Tenant as means to check, Nimbus cannot see any extended user presence status.

🤔 What happens after this setting is active?

When activating the presence tracking feature, call handling is handled according to the MS Teams status as follows:

Calls are delivered while Calls are NOT delivered while

Available

Busy*

Busy in a Meeting*

  • Away*
  • Busy in a call
  • in DND (Do Not Disturb)
  • Offline

💡 Note that Nimbus will adhere to Distribution Service Settings, so ensure to check there if your calls are not delivered as expected. 
💡 Note that Nimbus can still forward calls when you are in the middle of doing an outbound calls via Teams, as your presence status will only change when you are in an established call.

🔍 Also refer to the related Microsoft Documentation: User Presence States in Teams.

Guest User Details

✅ Before you can use the extended presence feature you need to invite two guests users to your tenant. The steps are described below.

  1. Within the Nimbus UI > Tenant Administration > head to the "Presence Tracking" section
  2. Take note and mouse over the "Presence Account 1 & 2" user mail addresses to see their details. 
    💡 These accounts are individual to your Nimbus cluster. Examples below have been blurred to prevent mistakes.
  3. Make sure to copy your individual presence account name, including the @ domain ending. The account details will be used in a step below. 
    Screenshot showing two individual presence accounts

Invite Guest Users

INC Invite Azure Guest Accounts

  1.  As Tenant Admin, log into your Azure Portal.
  2. Go to Users > New Users and select “Invite external User”.
     
  3. Invite both guest users 1&2 on your tenant. Add each of the previously copied email addresses (e.g. svr_nimbus_guest@onmicrosoft.com) and click Invite.
    ⮑ A standard Azure invite mail will be sent out to Luware.

    ☝ Note that MFA (Multi Factor Authentication) needs to be disabled for these users. Otherwise this feature will not work as the guest users cannot sign into your tenant.
  4. Let your Customer Success Specialist know that the guest users have been invited.
  5. Please wait while steps are done in the background:
    1. Luware cloud operations team must accept the guest invitations. Please allow for some time for this to happen.
    2. Once successful, the "Account is not added as guest" message should disappear on your side in the Nimbus admin UI.
    3. If this is not the case, please get in contact with the Luware support.

Grant Delegated Permissions

💡 This step can be done in parallel to the previous steps. Once granted, either of the presence accounts will make use of these permissions and no further actions are required on your side.

Copy & paste URL from the "Grant Permissions" area into your browser. This link must be opened by logged-in a Tenant Administrator in order to work.

🤔 Which permissions are granted to these users? Refer to Nimbus Required App Permissions > "Presence Tracking"


Results:

  • Once granted, the "Permission is not granted" note should disappear in the admin UI.
  • You can now enable the "Track Presence Over Guest account" feature and test the status tracking via the "Test UPN" field.

Adjust Your Service Settings

💡 With all previous "track presence" steps successfully performed, Nimbus is now able to distinguish between busy states.

✅  We recommend to check your Service Settings > Distribution > Conversations Distribution tab and have converations "Distributed to the user" even while busy. Nimbus will automatically detect if an existing Nimbus service call is already handled by that user and re-route incoming calls accordingly.

Secure Workaround for MFA

INC Secure Workaround for MFA

In some cases Nimbus will require you to invite Guest Accounts to support extended features on your Tenant. We realize that not using MFA for presence accounts is a big limitation. If your IT policy mandates MFA on all accounts, there is a workaround that whitelists IP ranges. To circumvent this problem you can use the following workaround:

  • Add trusted Locations with the Nimbus Server IP Addresses (Switzerland)
  • Add a conditional access policy to limit the access to the given trusted location.

Learn more…

Add Trusted Location

  1. Go to Named locations within Azure Portal (https://portal.azure.com)
  2. Add a new IP ranges location
  3. Enter a Name and add the IP addresses for the location and check the Mark as trusted location option
  4. Add all IP addresses for the location (see table below)

    and click on Create

Add a conditional access policy

  1. Go to the Azure portal (https://portal.azure.com)
  2. Switch to Conditional Access and select Policies
  3. Select an existing you want to change or create a new policy and configure the Condition section to add your trusted location as excluded from the MFA policy

Nimbus Cluster IPs

Switzerland 01 20.250.90.136 20.250.90.30 20.250.90.31
Switzerland 02 20.250.216.126 4.226.25.247 4.226.26.8
Germany 01 20.52.208.117 20.52.209.237 20.52.208.209
Germany 02 98.67.132.41 98.67.132.74 98.67.132.61
United Kingdom 01 20.49.226.86 20.49.226.93 20.49.226.126
Nimbus Cluster IPs provided by Microsoft (Status 27/02/2024):

Caution: These IPs are configured by Microsoft and can be changed without prior notice.

 
 
 

Troubleshooting

Error  Description Solution

Unknown Error (XX0000) 

Enhanced Presence has been enabled, Guest Accounts have been added, Permissions have been approved, Multi-Factor Authentication has been disabled for the Guest Accounts.

However, the following error message appears when trying to check the status of users: 

Solution A: Change global collaboration settings

  1. Head to In Azure Portal > Users > User Settings > External Users > Manage External Collaboration Settings.
  2. Set the "Guest User Access Restrictions" to either "Most inclusive" or "Limited access" 

This is a global setting and applies to all (future) guest accounts. If you do not want to change this, consider solution B below.

 
 
 

Solution B: Change individual user role assignment

Since the External Collaboration Settings are a global setting, you may not want to relax these rules just for one application. Instead you can just assign a special role to the guest accounts.

  1. Head to In Azure Portal > Users > Nimbus Guest Account > Assigned roles > Add assignments.
  2. In the "Membership" Tab, assign the "Directory Readers" role to the Luware Guest Account(s).
  3. In the "Settings" Tab, ensure the assignment is "Active" and "Permanently assigned"
 
 

After the setting is changed, it may take up to an hour for the Nimbus Enterprise App to properly read the users' presence data.

 
 
 
Test UPN

✅ We highly recommend to live-test the new presence accounts 1&2 individually and check different users on your Tenant to see if the extended presence status updates correctly. 

💡 The extended presence status should be shown / updated immediately. If you encounter problems with this or see an error message, please get in touch with your Nimbus customer success / onboarding contact.

 
 

Modalities

Modalities Tenant Settings

On the “Modalities” tab you can configure modality behavior affecting all users and services with the corresponding modalities enabled. Settings on this page are divided per modality accordingly: Instant Messaging, External Task, Email.

Modalities: Good to know

Instant Messaging External Task Email

You may not see all modality-related settings on your Tenant yet. Once enabled on your tenant you will see corresponding options available in the Modality Service Settings and General User Settings. We will inform in the Latest Release Notes about any enabled or disabled settings.

☝ All Modalities are separatedly licensed and require prior technical setup. Consult with your Customer Success partner to discuss licensing terms - and afterwards - refer to your License Management to check your available modality contingency.

 “Max concurrent task” parameters changed on this page immediately affect services which already make use the coresponding modality. Further incoming tasks will be blocked until the task backlog gets below the set threshold.

INC Fair Use Disclaimer

🤝 This feature uses runtime resources under a fair-use policy. Luware may change the usage limit or contact customers that exceed the general usage quota.

 

Instant Messaging

IM Preconditions

Once enabled, this option grants your Nimbus users Chat Handling capabilities and extends related features of Nimbus.

🔎 For detailed steps, refer to Use Case - Setting up Instant Messaging.

 
Area Description
Instant Messaging Required to enable the feature and show further options
Grant Permission As Tenant Administrator you need to grant permissions once. Paste this link into your browsers address bar or pass it on to a Tenant Administrator with according privileges.
Primary Account / Secondary Account Guest accounts to invite on your Tenant to enable Instant Messaging capabilities.
Test UPN Use this (after the successful user invite) to send test messages to any user within your tenant.
Max concurrent IM Tasks per Service

Max limit of concurrent Instant messaging tasks per service (similar to ET)

  • Default: 20
  • Min: 1
  • Max: 50
Use your own ACS Instance

Optional step. Only required when you don't want to use the default Nimbus ACS instance. 

Learn how to set up your own ACS Instance

INC ACS Instance Setup

INC ACS Instance Setup

The following steps describe how an ACS instance can be setup. Which is required for Nimbus Assistant and/or Interact.

INC Interact Azure Billing

AZURE BILLING

The usage of Interact will cause additional monthly ACS (Azure Communication Services) costs depending on modality (IM/AV) used. These cost are determined by Microsoft. Also see: https://learn.microsoft.com/en-us/azure/communication-services/concepts/pricing

  • Before enabling additional modality features for your services, get in touch with your Luware Customer Success specialist to discuss terms, usage scenarios, and necessary setup procedures.
  • Please note that Nimbus and Interact support does not cover pricing discussions or make recommendations based on the Microsoft Azure infrastructure.
 

Create new Azure Communication Service

To create a new Azure Communication Service perform the steps:

  1. Head to Azure Portal and login with tenant admin rights.
  2. Search for "Azure Communication Service" component and click "Create".   
     
    ☝ Make sure not to use any underline/underscores within the name.
  3. Switch to the Keys tab and copy the connection string  

 

 

 
 
ACS connection string

Connection string for Azure Communication Services. Required to use Chat Handling with your own ACS instance. 🔍 Learn how to generate this string via the Microsoft Documentation .

 

💡 Once a string is entered a "Check" option verifies if it's possible to create a token for the user using this string. If the connection fails (with a correct string) it most likely means there are insufficient permissions.

ACS Resource ID Connection ID for Azure Communication Services. Required to use Chat Handling with your own ACS instance. 🔍 Learn how to retrieve this ID via the Microsoft Documentation .

External Tasks

External Task Preconditions

Same as any other task, external tasks distributed via queue among available Nimbus users and shown in the Personal Dashboards > in the "External Tasks Tabular" widget.

Tasks are scheduled using the Microsoft Power Automate Connector > Flow Actions. Once the limit is reached, a flow error is returned and the task will be discarded.

🔎 Refer to Use Case - Creating an External Task  and Use Case - External Task in Combination with Nimbus Assistant.

 
Area Description
Max concurrent External Tasks per Service

Limits the maximum External Tasks per service that can be simultaneously scheduled / in progress

  • Default 20 / Min 1 / Max 50

🔍 Why is this limit in place? As external tasks can be created in bulk via external MS flow loop, this setting underlies a fair-use policy. This limit is also in place to ensure that potential erroneous loop conditions don't create a large amount of "stuck" tasks, blocking up service queues. Task processing resumes when the threshold drops below the limit.

Email Tasks

Email Preconditions

Once enabled, this option grants your Nimbus users Email Handling capabilities and extends related features of Nimbus.

🔎 For detailed steps, refer to Use Case - Setting up Email.

 
Area Description
Max concurrent Email Tasks

Limits the maximum Email tasks per service that can be simultaneously scheduled / in progress

  • Default 50 / Min 1 / Max 200

🔍 Why is this limit in place? As Email tasks can created in bulk - either intentional, SPAM or by misconfiguration, this setting underlies a fair-use policy. This limit is also in place to ensure that potential erroneous conditions don't create a large amount of "stuck" tasks, blocking up service queues. Task processing resumes when the threshold drops below the limit.

 
 

Licenses

License Tenant Settings

Here you can check and distribute licenses that enable/disable Nimbus FeaturesThe counters change when you Manage Licenses per service and users respectively, drawing from your current license contingency.

The different sections of this view are described in the following:

Tenant State

 💡Please note that this field is read only. Your status can only be changed by a Luware System Administrator. States displayed can be as follows:

  • Active - your Nimbus subscription is active and valid.
  • Trial - your Nimbus subscription is in trial mode. You can try out Nimbus Features within the trial period.
  • Suspended - your Nimbus subscription has been suspended.
  • Expired - your Nimbus subscription has expired. Get in contact with Luware Support if you need to renew it.
  • Canceled - your Nimbus subscription is cancelled.
  • Lab - a Nimbus lab subscription for test purposes.

🤔What happens on Tenant suspension? All users will not be able to login to Nimbus and related apps. Inbound / Outbound tasks will be rejected and incoming calls will be redirected to a default announcement workflow. This state can be resolved by a Luware Administrator.

 

🤔I'm already running Nimbus productively. What happens if my tenant state is not "Active" yet?

Your Customer Success specialist will reach out to you with further details on your license usage and the course of action. For any immediate questions on your License Management you can always contact Luware support.

 

Luware Support Address

 Luware Website https://luware.com/support/
Luware Helpdesk https://helpdesk.luware.cloud 
Cloud Service Status https://status.luware.cloud/
Luware support contact details

 

Service

Service Type Licenses

Shows your usage of Nimbus Service types

 What is the difference?
  • Advanced Routing - the default license for new new services.
  • Enterprise Routing - services with advanced features.
  • Contact Center - services with Contact Center features.
Feature Licenses

ABOUT SERVICE LICENSES

Refer to Nimbus Features for a detail comparison of available service licenses.

Licenses and Apps are managed via Service Administration > General tab

Visit License Management to learn more on how to change your service licensing in bulk

 

User

Service Type Licenses

Shows your usage of Nimbus user licenses. Refer to Nimbus Features for more context.

  • Contact Center User - the amount of users (Agents) with Contact Center features.
Feature Licenses
  • Attendant Console - the amount of users that have Attendant Console enabled.
  • Assistant - the amount of users that have Assistant enabled.
  • Interact User - the amount of users that have Interact enabled.
  • Transcription - the amount of users that have Transcription enabled (Live Caption included).

ABOUT USER LICENSES

Refer to Nimbus Features for a detail comparison of available user licenses.

Licenses and Apps are managed via User Administration > General tab.

Visit License Management to learn more on how to change your user licensing in bulk.

 

Modalities

Modality Licenses

Shows the number of allowed users per channel of communication.

 

 
 

Pushing Tenant updates

Pushing Tenant updates via Script

Major technical changes on a tenant-level or within service settings may require a re-execution of a downloadable Microsoft PowerShell script, using tenant admin privileges. The script will push those changes to Azure, and updates should be reflected within minutes.

A change pending for powershell script execution
🤔 Where to find the script? You can retrieve the script either from the your User Preferences (Portal) / User Preferences (Admin) or directly via the following links: 

Deleting a Tenant

Deleting a Tenant

The Provisioning PowerShell script is also used to push a pending deletion (unprovisioning) request of a whole tenant. 

PLEASE READ BEFORE DECIDING TO DELETE YOUR TENANT

🔍 This setting is available to Multi-Tenant Administrators only. Deleting a tenant will also mark all Nimbus services under that tenant for deletion.


✅ Confirm Check: As this cannot be undone, you have to confirm the deletion in a separate pop-up by typing out YES and confirming this step.


After your confirmation, these effects are to be expected:

→ Underlying Nimbus teams shift to pending deletion state in the Administration Overview and individual Service Administration views respectively.      
→ At this point Nimbus services will cease to operate.     
→ The next run of the provisioning script (see Nimbus Installation) removes the related team entries from Azure.     
→ When the provisioning script was successful, all Nimbus functionality is removed.

 

GOOD TO KNOW

Previously existing structures within your MS Teams instance - such as team definitions, channel names, team members / team owners - remain unaffected. Only Nimbus related tabs and functionality are removed from your tenant. 

 

 

 

Table of Contents