How Nimbus users relate to MS Teams Client roles

Within the MS Teams Client Nimbus will use your existing structures to authenticate any team members as users of Nimbus.

RoleInstallation-related TasksRelated links

TENANT ADMIN

Tenant Admin is required to execute the Nimbus Installation in your company tenant and

Tenant Admins or users with similar roles in your company start with the prerequisites on this page and related pages such as Nimbus Installation and Service Provisioning.

  • After the Installation you might want to learn about the Administration UI. It is accessible via the following URLs:

Admin Panel URLs:

(tick) Make sure to configure your web proxies to allow access to these domains or whitelist the complete *.luware.cloud domain.

TEAM OWNER

Team Owner is a service administrator in Nimbus and

    • can add the Nimbus application to the Teams Client when Nimbus Installation is complete.
    • can execute Service Provisioning (may require Tenant Administrator assistance where highlighted).
    • can change service Service Settings. Certain settings need to be approved by the Tenant admin.

Team Owners will mainly interact with Configuration and Service Settings on their related services.

  • Being involved with building new Nimbus service teams, it's important for team owners to know about the different Service types and how Users are assignment . Nimbus currently syncs your Tenant users in the following ways:
    • MS Teams-based: Directly tied to your "Teams" the users get automatically added to a Nimbus service
    • None: For IVR or first-level redirection services
    • Skill-based: Manual skill-assignment from users you add from within your tenant directory.

TEAM MEMBERS

 Team Member is a service user (or agent) in Nimbus and

Team Members are primarily interested in the Usage of Nimbus. Same as Team Owners they access the UI via the following URLs:

Portal URLs:

(tick) Make sure to configure your web proxies to allow access to these domains or whitelist the complete *.luware.cloud domain.

GUEST MEMBERS

Do not exist in Nimbus.None - Unauthenticated guest members have no access to Nimbus features.

(info) Please note that we use the terms "service" and "user" in Nimbus to differentiate towards existing MS channels and its "members" respectively. More details can be found in the Nimbus Glossary and User Permissions

Script execution and impersonation permissions

Nimbus is deployed and (re)configured using Powershell scripts.

  • You need Tenant permissions to use Powershell for Nimbus deployment. (info) More infos on Provisioning via Microsoft PowerShell
  • On first script run we highly recommend to start the Powershell session as administrator to ensure that necessary dependencies are installed. Our scripts will retrieve dependencies automatically an install them on your running PC if necessary.
  • A re-execution is needed for every service team deployment or service update as the changes need to be pushed to Azure.

External Communication and MS Teams Presence


External access required

TENANT ADMIN You need your tenant to allow external communications with the "luware.com" domain.

(info) The necessary configuration steps are described in the Microsoft Teams Documentation: Manage external Access.

You will also need to disable the "Enhanced Presence Privacy Mode" policy which prevents visibility of the Teams Presence.

The "Enhanced Presence Privacy Mode" is a global configuration which, if enabled, prevents all external organizations from viewing the Teams Presence status of your users via Teams Federation.

(warning) If this mode is enabled, Nimbus will see all users as permanently Offline, and thus won't be able to distribute calls to them.

(lightbulb)This is a legacy configuration option used in Lync / Skype for Business which is not available anymore in the Microsoft Teams Admin Center and can only be viewed and configured via PowerShell. It is a global setting that always applies to all users and cannot be deactivated or bypassed for individual users.

You can check whether this is enabled in your tenant by running the following PowerShell command:

Get-CsPrivacyConfiguration | Select EnablePrivacyMode
POWERSHELL

The command will return "True" if the Enhance Presence Privacy Mode is enabled, or "False" (default value) if it is disabled.

To deactivate it, run the following command:

Set-CsPrivacyConfiguration -EnablePrivacyMode $false
POWERSHELL

(question) Why are these steps necessary? Without being able to read the Teams presence data of your users, Nimbus will consider them as Offline and thus not available for call distribution. They will not be able to receive any inbound calls or place any outbound calls via Nimbus.

PSTN Licensing


Transfer to PSTN limitation


Out-of-the-box, Nimbus and affiliated addons can only perform PSTN transfers according to Microsoft's licensing and constraints.


Which PSTN license do I need to acquire?

(tick) As a tenant administrator you need to acquire the following licenses and assign them to the application instance of the respective Nimbus SOURCE service (team) that will act as PSTN transferor:

Your SetupRequired License
Direct Routing"Microsoft Teams Phone Resource Account"
Calling Plan"Microsoft Teams Phone Resource Account"
+ "Microsoft Teams Domestic Calling Plan" or "Microsoft Teams Domestic and International Calling Plan" or "Microsoft Teams Calling Plan pay-as-you-go"
+ "
Communication Credits" (if these aren't already included as part of your plan)
Operator Connect
"Microsoft Teams Phone Resource Account"


(warning) As of 2023 "Microsoft Teams Phone Standard" licences are no longer supported by Microsoft. Previously those licenses were viable for Nimbus. → Regardless if you are using Direct Routing, Calling Plans, Operator Connect - the "Microsoft Teams Phone Resource Account" license is now always required

(warning) Please note that Luware staff cannot make recommendations on which license plan is best suited for your needs. Depending on your scenario, additional Teams App licenses may be required. Exact details are to be discussed with your Microsoft contacts.


(info) Also see: https://learn.microsoft.com/en-us/microsoftteams/teams-add-on-licensing/virtual-user


How does PSTN licensing affect Service and Call Transfers?

Assuming that Service A has a PSTN license assigned - but further Services don't - the following scenario may unfold:

  • Scenario A - Service A workflow is configured to transfer the caller to Service B. The license of Service A is used, the PSTN transfer occurs. The PSTN license is re-used throughout further transfers to Services C..D...x.
  • Scenario B - Service B is called directly instead. Now the workflow of Service B attempts a redirect to either service A or transfer to C. The PSTN transfer fails due to a missing license on Service B.

Learnings

  • For one first-level-response Service: If you handle first-response calls always via the same Service you need a PSTN license for that particular first-level Service.
  • For multiple first-level-response Services: If you handle first-response calls always via multiple Services you need a PSTN license for all those first-level Services .
  • Nimbus will attempt to use the PSTN license of the first service that responded to a call, regardless of how many further internal service transfers are performed thereafter.
  • If no PSTN license is found on a service that requires it for a transfer, the transfer task will be considered as failed and be treated as such by the system (e.g. workflow exit announcement, reporting "transfer failed" outcome).

(warning) Note that handling and tracking of running cost for PSTN licenses is outside of Luware support scope.
If you require assistance in extending and/or configuring your Nimbus services for PSTN our support will gladly assist you:


(info) Refer to the external reference: Microsoft Teams PSTN connectivity options and Microsoft Teams add-on licenses.

Phone Number configuration

When managing your Phone Numbers for usage of Nimbus services, please note the following:

  • If you're using "Direct Routing" (Numbers managed outside of Teams) you can assign any phone number to a Nimbus service.
  • If you're using calling plans for Microsoft you can only assign a "Service" number type. "User (subscriber)" type numbers will not work.

Further information can be found on in the MSFT documentation: Types of phone numbers used for Calling Plans.

Design Limitations and Limited Support Scenarios

These scenarios may work for Nimbus under certain conditions, but are not officially supported by Luware. Note that our support team cannot assist you in these cases.

ScenarioRationale
Operating Systems other than Windows 10 or 11

We at Luware are committed to get the best experience possible for our Windows 10/11 user base. However we are committed to adress any requests and concerns and will prioritize our future development based on frequent user feedback.

Mobile Device Support (Android / iOS)

Mobile device support for Nimbus (both Android and iOS) is currently not a focusHowever we are committed to adress any requests and concerns and will prioritize our future development based on frequent user feedback.

Teams Web Client


Design Limitation on Microsoft Teams Web Client

The Teams Web Client currently has a known limitation that sends a lot of incorrect status updates especially when refreshing the page in your browser. This has a noticeable impact on how Nimbus handles Agent presence, availability and reporting features.  

Causes and Workarounds

Microsoft treats web-based Teams Clients presence status changes differently and with seemingly lower priority. The effects include:

  • User sporadically appearing as offline.
  • Spontaneous switch to an erratic presence status which is apparent in logfiles.
  • Multiple status updates within only a few seconds, which increases when user is refreshing the Teams chat window within the browser.

Until this is resolved by Microsoft we strongly advise to exclusively use a locally installed Teams Client App for all productive users of your organization.

"Auto Attendant" and "Call Queues" (Teams native)


Transfer to Teams-native "Auto Attendants" and "Call Queues"

Nimbus does currently only support call-forwarding via Blind transfer to either UPN or PSTN numbers of Teams-native "Auto Attendants" and "Call Queues". Any safe transfer or consultation attempt will lead to a call abort.

Causes and Workarounds

This is caused by Microsoft Teams limitations and cannot be circumvented by Nimbus.


(lightbulb) A possible workaround would be to force the call over your Direct Routing SBC by using an internal dummy number that isn't otherwise associated with any other Teams user or service already. This call would then be routed to your SBC, which can then re-direct it towards the actual number of the Call Queue / Auto Attendant on the Teams side again. As this workaround is dependent on voice infrastructure components outside of Luware's control and support scope, please reach out to your SBC provider or skilled personnel for its implementation.

(lightbulb) The above mentioned workaround is not technically feasible if you are using Microsoft Calling Plans or Operator Connect to provision numbers directly through Teams. Forcing an external reroute as a workaround is not possible with these numbers.

Virtual Desktop Infrastructure (VDI)


Using "Virtual Desktop Infrastructure" (VDI) with Nimbus

Nimbus does not directly support a Virtual Desktop Infrastructures (VDI). Users will see themselves unable to log into neither Nimbus portal or admin URLs.

Causes and Workarounds

Instead of logging into Teams itself, a VDIs redirect the user to a browser window for logging into the Nimbus app. This causes a problem with the login because the token flow doesn't come back to the app within the Teams client. In Nimbus this poses a security risk and is thus considered a non-supported scenario.

→ The only solution on a VDI is to train your users to login to portal.luware.cloud directly, using Nimbus in their browser instead.


(lightbulb) Please note that Luware support cannot assist with your VDI configuration. While this scenario may work with an adapted proxy / component configuration on your Tenant, Luware cannot safely guarantee that all customer-side VDI configurations work in this scenario.