The Nimbus "Tenant" view allows to assign security groups and change tenant details

Access Tenant details

As administrator you can use the " Edit " button for each tenant to access and change details.

Tenant Information

Within here you can check on details for 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 Roles and Permissions. For instance, single tenant admin permissions may restrict you to only edit non-technical information such as: 

  • Company Name / Division 
  • Billing Address
  • Technical Contact

(info) Note that clicking on a Service within a tenant leads to → Service Administration .

(lightbulb) Note: Depending on Roles and 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 customer support.


SectionOption / ElementDescription
Tenant InformationName

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 NameClear 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.

(info) 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.

(info) 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.

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

(lightbulb) 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.

CRM IDID 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.

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

Technical Contact

Technical Contact

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

Support contact for this partner tenant.

PartnerSelect Partner

Allows you to select and reassign a (new) Partner to this tenant.

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

Support

Allow Partner to see User Identifiers

(lightbulb) Setting is defined by Tenant Admin

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

(lightbulb) Setting is defined by Tenant Admin

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.
MS Graph Filter

A global Azure Directory "Contact Search " Graph Filter

  • TextBox
  • Default: Empty

Uses the MS Graph REST API to filter users according to your tenant admin account permissions.

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


(warning) 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 copy & paste your updated filter parameters.

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

(info) Refer to our Use Case - Filtering Attendant contact search via MS Graph.


Example filter

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

Notes and known limitations

KNOWN LIMITATION The filter will be applied to all O365 accounts, including those of Nimbus Services!


  • This text field does not perform validity checks for correct syntax. → Please refer to the official MS Graph REST API documentation for details.
  • 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. Otherwise search functions in Attendant Console might not work at all.
  • If the filter query is broken (e.g. missing permissions, typos, syntax) then search might not work at all.
  • When a frontend user (e.g. via Attendant) searches within the same fields as defined in your query there can be a clash as Nimbus combines both visible and backend filters with an 'AND' clause.

Interact

(info) This section allows you to enable and configure Interact. If you need to know more about this feature, 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.
ACS connection string

Connection string for Azure Communication Services.

(info) Learn how to generate this string via the Microsoft Documentation .

(tick) "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 UserIDID 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.

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.

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)

(info) 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

(info) 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

(info) 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

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

Presence Tracking

(tick) "Presence Tracking" allows Nimbus to make smarter routing decisions by determining if your users are already in a (non-Nimbus) call. 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.

(info) Also see related Microsoft Documentation: User Presence States in Teams.

(question) 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. 
  • An example is the "Available when Busy" setting in your Service Settings. Nimbus can now distinguish the "Busy" extended status and plan/avoid call distribution accordingly.

KNOWN LIMITATION For "Away" and "BRB" states the "In a Call" extended status cannot be returned by Microsoft. In cases when any of these statuses were manually set by users, Nimbus doesn't have any additional information that users can be In a Call and will follow the 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)
(tick) 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.
(lightbulb) 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

(question) 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.

(tick) T o 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.

(info) These guest accounts require extended permissions → see "Grant Permission" above.

Preconditions

Guest user details

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

Within the Nimbus UI > Tenant Administration > Presence Tracking copy the "Presence Account 1 & 2" user mail addresses to clipboard or a text file for later reference.

(lightbulb) These mail addresses differ depending on your Nimbus cluster, so the screenshot above is just an example.

Invite Guest Users

  1. As Tenant Admin, log into your Azure Portal.
  2. Go to Users and select Add a new "Guest User".

  3. Invite both guest user 1&2 on your tenant.
    Add each of the previously copied Email-addresses and click "Invite" → A standard Azure invite mail will be send out to Luware.
  4. (warning) 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.
  5. Let your Customer Success Specialist know that the Guest users have been invited.
  6. 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 from your side in the Nimbus admin UI.
    3. If this is not the case, please get in contact with support.

Grand delegated permissions

(lightbulb) This step can be done in parallel to the previous steps. Once permissions are granted, either presence account 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.


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

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

(tick) 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.

UCIDUC  NIMB 028

Test UPN

(tick) 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. 

(lightbulb) 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.

Push Tenant updates

Major technical changes on a Tenant-level may require a re-execution of a downloadable script which must be executed with tenant admin user elevation. The script will push those changes to Azure, and updates should be reflected within minutes.

(info) Related info can be found on: 

Delete a Tenant

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.


(tick) 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.