Tenant Administration

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.

• 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 Unit, Responsibility Profiles (User State), MS Teams Presence Status and all related event changes with timestamps and durations.

 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 

Factor	Definition / Conditions	Nimbus-Tracked User State
Presence in MS Teams	Online – including status "Busy" or "Away" –  if defined per Service-individual Distribution Service Settings.	Offline	Online  MS-Teams based services will distribute when "Active".	Online and set "Active" MS-Teams based services will distribute.	Online and "Active" but Busy/Away Can either be selectable or not ⬇️ (determined per each Service's Distribution Service Settings)
Duty State Contact Center	User is online and has any "On Duty" responsibility profile selected. User is assigned to the Service as "Agent" via Agent Service Settings.		OffDuty An "OffDuty" responsibility profile prevents any Contact Center participation.	On Duty Any "Duty" type responsibility profile allows Contact Center participation. Skills and Responsibilities in that profile must match the service to be "Selectable". This is determined by the individual Distribution Policies assigned to the respective services.
Task selectability	"In Time" available to perform tasks in Nimbus: Online in MS Teams. Set to "Active"  in any Teams-Based  Nimbus service or In a "On Duty" profile for Contact Center services.			"Selectable" state This includes Busy/Selectable and Away/Selectable	"Non-Selectable" State, either because: ⬆️ User is not available either due to the Presence state in MS Teams or set "inactive" for all Nimbus teams or ⬇️ ... any existing or previous Call Status marks the user as "Not Selectable
Call status	Reserved and blocked for a Nimbus task. Any of these status flags occur during or after a call and prevent selection for further tasks until resolved.				Not Available Reason Requested as the user changes MS Teams presence (manually or from idle).	RONA (Redirect on No Answer) User flag after not responding to a task, blocked for the next tasks.	Ringing User reserved for new task, but has not accepted yet	Connected User accepted task, is blocked by it.	ACW (After Call Work) User has a fixed (optionally extensible) timespan to complete work after a call.

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.

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.

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 Permissions).

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

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

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

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:

• Add a client secret
• Add a certificate

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

Uses the MS Graph REST API to filter¹ 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'

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.

---

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

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.

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:

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.

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.

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

• 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

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

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

If 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.:

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

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 provided by Microsoft (Status 04/21/2023):}

• Switzerland: 20.250.90.136 / 20.250.90.30 / 20.250.90.31
• Germany:     20.52.208.117 / 20.52.209.237 / 20.52.208.209
• UK:               20.49.226.86 /  20.49.226.86 / 20.49.226.126

Subject to frequent change

The IPs are configured by Microsoft and can be changed without prior notice. Please refer to the Microsoft Documentation

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 Head to In Azure Portal > Users > User Settings > External Users > Manage External Collaboration Settings. 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. Head to In Azure Portal > Users > Nimbus Guest Account > Assigned roles > Add assignments. In the "Membership" Tab, assign the "Directory Readers" role to the Luware Guest Account(s). 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.

UCID	UC  NIMB 028

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.