Extensions Tenant Settings

Configure behavior of Nimbus UI Extensions and Apps

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

Directly invite PSTN for Outbound calls

If enabled, PSTNs are directly added to a group call in case of a scheduled outbound session or Call On Behalf, avoiding audio delay between agents and customers.

  • Default: false

🤔 Why is this toggle read-only?

Enabling this feature is done by Luware Support and requires testing on your tenant as Microsoft has not yet rolled out dependent functionality globally for all MS Teams tenants.

Directly invite UPN for Outbound calls

If enabled, UPNs are directly added to a group call in case of a scheduled outbound session or Call On Behalf, avoiding audio delay between agents and customers.

  • Default: false

🤔 Why is this toggle read-only?

Enabling this feature is done by Luware Support and requires testing on your tenant as Microsoft has not yet rolled out dependent functionality globally for all MS Teams tenants.

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.

Interact disabled

If Interact is disabled, all corresponding fields are hidden in the section.

💡 Configured values are not cleaned up and can be used when enabling the functionality again.

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.

💡 When this option is disabled, all corresponding fields are hidden in the section. Configured values are not cleaned up and can be used when enabling the option again.

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
Use new Attendant Console Design If toggled on, Nimbus users of this tenant can switch to the new Attendant Console design (AC2).
Overwrite User Settings Applies the old/new Attendant Console design to all users, depending on whether “Use new Attendant Console Design” is toggled on or off.
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 (via Application Permission)

"Presence Tracking" allows Nimbus to make smarter routing decisions by determining the extended presence state, e.g. 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 the support in case you need assistance.

Needed permission is:

  • Presence.Read.All (Application)
Extended Presence Tracking

Without the required permission for extended presence tracking, Nimbus can only retrieve a simplified presence status such as "Busy" "Away" or "Available" for your users. The permission is required for status presence such as “Busy → In a Call “ or ”Busy → In a Conference” in order 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. When any of these status were manually set by users, Nimbus doesn't have additional information whether 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.

 

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

If you want to keep using "Presence Privacy mode" on your Teams tenant, you need to allow Nimbus to track extended presence. Otherwise Nimbus cannot route anything because presence states will not be available to Nimbus.

Grant Permission with Grant Link
  1. Go to  Extensions Tenant Settings.
  2. In section Presence Tracking, click the grant permission button.
    ⮑ This will ask you to sign in with your account.
    💡 You need to sign in as a Tenant Administrator for granting the permission.

    ✅ A green checkmark is shown if the permission was granted successfully:
  3. Click Test Connection and enter your UPN if the permission was granted successfully.
Grant Permission via Provisioning Script
✅ Granting permission by running the provisioning script is an alternative to granting via Grant Link and also requires Tenant Administrator rights.
To grant the permission this way, run the provisioning script as a Tenant Administrator.
Test UPN

You can check if the permission was granted successfully:

  1. Go to Extensions Tenant Settings > Presence Tracking.
  2. Click Test Connection and enter your UPN.

Table of Contents