Tenant Administration
The Nimbus "Tenant" view allows to assign security groups, change tenant details and configure various Nimbus Features and extension apps.
Access Tenant details
ADMINISTRATOR As 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.
Tenant Configuration Tabs
Please Note
|
Here you can change and enter details on your tenant, change or access the billing address and / or technical contacts.
View differences
The Tenant administration may look different for single- and multi-tenant admins.
Access to configuration elements is determined by 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 Role Access Concept, 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 customer support.
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. | |
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. | |
About Security Group permissions If fields are greyed-out they are managed by a higher permission level. Refer to Roles and Permissions for details.
| ||
CRM ID | ID for your Customer Relationship Management tool. | |
Billing Address | Billing Address
| Address of the partner to which the bill for this tenant should be sent to.
|
Here you can specify a technical contact to notify in case of maintenance, issues and for other technical questions:
Technical Contact | Technical Contact
| Support contact for this partner tenant. |
---|---|---|
Partner | Assigns a Partner to this tenant. | |
Here you can configure user-related data privacy settings.
Settings in this section may be visible/restricted to Luware and Partner administrators. Visit our website to learn more about the → Luware Partner program .
Option / Element | Description | ||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Allow Partner to see User Identifiers | Determines if the partner is able to see Nimbus user (team member) clear names.
| ||||||||||||||||||||||||||||||||||||||||||||||||||
Allow Partner to see Customer Identifiers | Determines if the partner is able to see Nimbus calling customer identifiers.
| ||||||||||||||||||||||||||||||||||||||||||||||||||
Track User States | Contact Center This feature can be enabled Tenant-wide, but mainly makes use of Contact Center service features for reporting. With this feature active, extended User States are tracked and added as part of the Nimbus Reporting Model , and exposed via the Nimbus OData interface.
Click to learn more about User States ...
For its Reporting Model Nimbus distinguishes sessions by various user state factors (Teams Presence, Duty State, Task Selectability, Call Status). These factors layer upon each other, meaning that
|
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.
|
---|---|
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:
|
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:
|
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.
|
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
|
ACS connection string | Connection string for Azure Communication Services. Required to use Interact.
|
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.
|
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:
|
Authorization | Determine if a session requires further authentication:
Learn how to set up authorization...
Steps below refer directly on the Daemon application MSFT help article and the subchapters. Create an Azure Application
Generate Secret / Certificate
Create own Daemon App with .NET/Java/Node/Python
Acquire a token and pass it to the SDK
|
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.
|
ACS connection string | Connection string for Azure Communication Services. Required to use Assistant with your own ACS instance.
|
Instant Messaging
Features described in the following are still in beta (experimental) stadium.
- Features marked with are still being evaluated in both performance and usability by both our users and the development team.
- Notable limitations and bugs may occur. An experimental feature may be temporarily disabled as improvements are implemented.
- Based on customer feedback, scope and design of the feature may change significantly in upcoming updates.
Configures Chat Handling capabilities and related features of Nimbus.
Option / Element | Description |
---|---|
Use your own ACS Instance | Toggle. Enable when you have your own Azure Communication Services instance.
|
ACS connection string | Connection string for Azure Communication Services. Required to use Chat Handling with your own ACS instance.
|
ACS resource ID | Connection string for Azure Communication Services. Required to use Chat Handling with your own ACS instance.
|
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. 1 See: https://docs.microsoft.com/en-us/graph/api/overview
Example filter for users within domain and preferred language:
CODE
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.
|
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.
|
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.
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:
| ||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Grant Permission (Copy to Clipboard) | Extended permissions are:
| ||||||||||||||
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. Click here for setup steps on your Tenant
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
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.
When activating the presence tracking feature, call handling is handled according to the MS Teams status as follows:
Guest user details
Screenshot showing two individual presence accounts Invite Guest Users
Grant delegated permissions
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.
Results:
Adjust your Service Settings
Secure Workaround for MFAIf you need to have MFA on all accounts, there is a workaround that whitelists IP ranges. Show me how to do this
We realize that not using MFA for presence accounts is a big limitation. To circumvent this problem you can use the following workaround.:
Add Trusted Location
Add a conditional access policy
Nimbus Cluster IPs provided by Microsoft (Status 04/21/2023):
Subject to frequent change The IPs are configured by Microsoft and can be changed without prior notice. Please refer to the Microsoft Documentation
Troubleshooting
| ||||||||||||||
Test UPN | |
Pushing Tenant updates
Major technical changes on a Tenant-level 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.
Where to find the script? You can retrieve the script either from the Nimbus Frontend Portal > User Preferences (Portal) or via the following links:
Deleting a Tenant
This setting is available to Multi-Tenant administrators only.
The provisioning script is also is used to push a pending deletion request of a whole tenant.
Please Read BEFORE deleting a Tenant
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.