Handling calls in Nimbus leverages MS Teams call features in both Inbound Service Calls and Outbound Call direction. The main difference is that Nimbus is establishing a Conference between you as Team Member (also called Nimbus "Users") and the calling Customer. By inviting a Nimbus bot into Teams conferences Reporting metrics can be tracked in the background and additional participants can be managed in a Conference. To achieve this the Nimbus bot uses Nimbus App Permissions which are usually delegated by an Administrator.
Primary views
As a Service User (Team Member) you can focus on your personal call experience in Nimbus. Within the UI you can steer your Service availability, access reporting features and handle tasks, as explained further below on this page.
To keep your experience as simple as possible, Nimbus has a reduced set of "daily-driver" views, such as:
- My Overview to check your incoming tasks and daily metrics.
- My Sessions to handle your incoming calls and related After-Call Work (ACW).
- Attendant Console – in cases where you act as a front desk operator for call forwarding and consultation.
Call Monitoring and Distribution
As a Service owner you may be more interested in monitoring your team and adjusting your Service parameters as needed. Therefore, your daily call-handling focus should be on the following areas:
- Services Overview to quickly see the incoming load of incoming calls, compared to the availability of your Service Team(s).
- Live View to quickly check on individual Services and their daily KPI trends.
- Personal Dashboards to monitor and supervise specific Services or Users.
- Configuration and Service Settings to optimize the call distribution parameters within your Services.
Learn more about this…
As Service Owner you also want to steer the channels of communication, via specific Workflows that contain Workflow Activities for further customization. Applying these settings is done via the Modalities Service Settings
Nimbus also considers individual User presence status (as set in MS Teams) prior to distributing calls. This allows to even include Users that are - for example - set to "Away" or "Busy". This can be configured in the Distribution Service Settings.
🔍You can also visit and learn more on the User States and Task Queue and Distribution pages.
Handling Incoming calls
While handling calls in Nimbus:
INC Nimbus and MS Teams native functionality
☝ While handling Nimbus tasks, avoid MS Teams-native call controls
During an ongoing session, Nimbus cannot control any functionality engaged in parallel via MS-Teams
(e.g. putting Callers On-Hold, Transfers, adding participants to a Session, Muting of participants).
✅While handling Nimbus tasks:
- Instruct all Service Users NOT to mix the approach between Nimbus and MS Teams.
-
Prefer the available Nimbus UI options for any call handling and -transfer scenarios:
e.g. Attendant Console (Safe/Blind transfer, Consultation call), Hold and Retrieve, Parking.
🤔What are the effects of using MS-Teams in parallel?
When using MS-Teams functionality in parallel during a Nimbus Session, the User / Customer experience cannot be clearly guided or monitored by Nimbus anymore.
Possible effects are:
- Customers may not get clear feedback on certain actions (e.g. no On-Hold Music - just silence).
- Manually added participants in a call conference may not all hear each other as intended.
- The status in Nimbus UIs may not reflect the actual state of a Session anymore.
- Call metrics, KPI and Nimbus Reporting results may not be properly recorded.
Nimbus is designed to not obstruct your daily call handling operation with Microsoft Teams. Most interactions rely on basic MS Teams functionality wherever possible, while extending functionality with rich context and call-related work. Let's explore the typical steps in the following chapters:
Call Distribution
- The Customer locates and calls your Service (discoverable either via Teams search, configured PSTN Number or known SIP Address as configured in the General Service Settings.
-
Nimbus handles the call according to your Workflow configuration. The call is added to a task queue and distributed according to the parameters specified in the workflow "Queue" Activities1.
💡In this example we continue with a "Pickup" type distribution2.
🔍Learn more by reading Distribution Types. -
Nimbus now will show the call in its UI, within multiple views wherever relevant to the involved Service Users. For example…
- … in the “Tasks Widget” in the Dashboard,
- … the Live View or …
- … My Sessions for the Users that actually get the call distributed to them.
1 When enabled in your “Queue” activity, an Adaptive Card chat message will also be sent to your chat channel in MS Teams. All current "Active" Nimbus Users are mentioned individually to be notified of this incoming call.
2 Even while being set "Active" for the respective Nimbus team, Users might still see inactive "Pickup" controls. This is determined by Service Settings > "Conversations Distribution", which defines that Users in "Away" or "Busy" state are also considered for call distribution.
Call Establishment
💡 In this example below we continue with Adaptive Cards enabled as a better visual example.
- Let us assume that a User in your team chooses to accept the call by clicking "Pickup"
🔍 This can be done either in the Dashboard, or the "My Overview" area in the Nimbus Personal App.
💡 The Adaptive Card also offers "Pickup" controls.
- Once "Pickup" is clicked Nimbus will establish a session between Caller and Agent
⮑ The User will get a regular MS Teams incoming call (in the name of the Service).
⮑ Nimbus will remain in control of the session for gathering Reporting KPI metrics. - Eventually, Agent and Caller decide to end the call
⮑ The Nimbus bot remains until both parties have left the call, then concludes the session.
⮑ In the background, a Nimbus Reporting session is concluded.
Call Conclusion
At the end, the call information will be gathered and reported, for example as Statistics and within the Sessions List.
The will also be updated with the Live View, as the Status of the User becomes “Available” again after handling the task.
The Adaptive Cards in your team's chat channel will also update with information about who / when / and if the call was handled.
Duty States & Responsibility Profiles
💡The following content is taken from the Duty States page.
Duty States
Duty States are the Nimbus way to signal if you are on or off duty. As part of Responsibility Profiles, they add an extra layer of conditional availability.
🔍 Using Assistant all Contact Center users can switch their duty state – and underlying responsibility – at any time. This can be done to adapt to various situations such as:
- Requirements for certain Skills and Responsibilities - e.g. when more experts are needed to bolster the usual service after a large technical change.
- Based on workload - Switching to a "highly-available" profile to take more calls from multiple services.
- Based on off days - e.g. Switching to a low-responsible mode, during absence or when abroad.
- Based on work situation - Switching between on-duty and off-duty profiles, e.g. when on a business trip.
Contact Center Service Type feature Enabling this feature will show Assistant with a main menu with a duty state / responsibility profile selector. These profiles are defined by your service administrator.
PREREQUISITES
Users of this feature must be part of a Contact Center service and also Contact Center licensed themselves.
→ Contact Center Assistant icon becomes visible in your main menu.
OPTIONALLY, any Administrator can then do the following:
- Create and assign one or several Responsibility Profiles to your user. These will be visible as additional entries in both Assistant standalone App and Nimbus UI.
-
Any admin can also define Skills and Responsibilities on your user account and define them per responsibility profile.
💡 Note that these skills are not visible to you, but can be adjusted by your team administrator via Agent Service Settings.
💡 Note: Regardless of Contact Center Duty State, you can remain fully "Available" to handle calls from other (non Contact Center) services. Read more on this in the chapter below.
Switching Between Your Duty States
- Login to the Nimbus Frontend portal.
- Note the new main menu item named "Contact Center Assistant" in the main menu.
- Click on it to change your duty status (and thus the related responsibility profile) at any given time.
STATUS PERSISTENCE
- Note that naming and amount of entries may change at any time, as managed and saved by any Nimbus administrator.
- Your status persists even when restarting your MS Teams client or logging out and back into Nimbus.
- You keep the last selected status until you either switch to a different one – or until an Admin changes the setting on your user.
Duty State in Responsibility Profiles
When you create a new Responsibility Profile in Configuration > Responsibility Profiles, you can decide whether it's an on-duty or off-duty profile. By default, responsibility profiles are on-duty profiles. You can change that by switching the Duty toggle.
💡 Note that you can only set the duty state of a responsibility profile as a part of the creation process.
The duty state of responsibility profiles is shown in the list:
When assigning a profile to the user, the duty state of their profile (on duty / off duty) is shown in various Nimbus areas, e.g.:
- … on User listings in the Administration.
- …in Assistant
- …on Non-Personal Dashboards
GOOD TO KNOW
Custom off-duty profiles are treated the same way as the system's default Off Duty profile, meaning that
- … they are tracked accordingly in User States.
- … if the user has a custom off-duty profile assigned, they are into taken into consideration for skill-based routing.
- … the current off-duty profile is outlined on the frontend.
Duty State Effects on Service Availability
Toggling your duty state affects a small colored indicator icon next to the menu entry.
The icon colors indicate your availability as follows:
| Icon color | Service availability condition | Related Responsibility Profile & Duty status notes |
|---|---|---|
| Gray Icon |
Shown when you put yourself off duty via the Contact Center Assistant menu:
|
Off Duty 💡 Note that your "Off Duty" Responsibility Profile can appear under a different name as administrators can change it. |
| Green Icon |
Shown when you put yourself on duty via the Contact Center Assistant menu. You will be selected for tasks when:
|
On Duty (Available) 💡 Note that multiple Responsibility Profiles can be of type "On Duty", but call distribution to you varies by Skills and Responsibilities behind each profile. 🔍 Also see "Status Dependency" infos below. |
| Red Icon |
Shown when you put yourself on duty via the Contact Center Assistant menu, but:
|
On duty (but not Available) - 🔍 More infos on this below. 🔍 Also see "Status Dependency" infos below. |
STATUS DEPENDENCIES
Switching your Duty Profile will not affect your MS Teams presence status and vice-versa. As a result you can still remain "Available ( green) " in MS Teams – e.g. to take internal calls – but appear (Red) in your duty profile, effectively blocking Contact Center related service-tasks.
- Toggling between Responsibility Profiles (Duty States) affects call distribution based on your Skills and Responsibilities. You can learn more about how this algorithm works on the Distribution Order page.
- If you are part of other (non-skill-based) services you may continue to use the "Active" on/off toggle e.g. in Services Overview at any time.💡 Note that this toggle is not present on skill-based services.
Status Q&A and Troubleshooting
🤔 Why is service participation reflected differently in the UI?
- For MS-Teams based services, Nimbus distributes calls evenly among "Active" users, usually to the user "Longest Available" in MS Teams.
- In a Contact Center scenario, Responsibility Profiles allow for much finer control over availabilty. Your duty status changes reflect on all Contact Center services simultaneously, e.g. by making you a first or second-level responder based on your profile and skillset.
- In both scenarios your status doesn't just reflect MS Teams presence, but various other User States.
🤔 Why are my "Active On/Off" toggle controls disabled?
- Note that each service owner can opt out of this feature via User Service Settings by unchecking "Team member can change active state". This can be done individually per service.
|
|
🤔 Are wrong calls getting distributed to you?
- Talk to your service administrator to have a look at your user skills via the Agent Service Settings . Also check if the Distribution Policy of that service matches Skills and Responsibilities set on your user account.
- Users who never signed in to teams will have the Presence “Unknown” set until their first sign-in. To avoid erroneous call distribution we suggest, that Administrators assign an "Off Duty" Responsibility Profiles profile as the initial default.
🤔 Is your status "Red" although you are ready for new tasks?
- Check if your User State is considered "selectable" as per Distribution Service Settings (e.g. Available when Busy / Away) and other flags such as RONA aren't blocking you from getting new tasks.
💡 Rule of thumb: Nimbus will distribute calls only when all "selectable" criteria are met: MS Teams Presence > Not blocked by calls > In a Duty Profile > Not status-flagged by ACW or RONA
Show me how to check this...
🔍About User States:
User States
For its Reporting Model, Nimbus performs checks on various User States. You can think of this as a multi-factor validation performed by Nimbus in order ensure a user is ready (and suitable) to take an incoming task from the internal queue. In short, the user is either considered as “selectable” or “not selectable”.
| Factor | Tracked User State relevant to Nimbus | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Teams Layer (monitored by Nimbus, always manually controlled by user) | |||||||||
| Presence in MS Teams | User is not present on the machine | User can make and receive Non-Nimbus calls. | Online AND set to any presence that Nimbus considers “not selectable” | Online AND set to any presence that Nimbus considers “selectable” Set to any presence that Nimbus considers “selectable” ▼ | |||||
|
Offline (Appear Offline) |
Signed in | DND | Busy in a call | Busy |
Away (Appear Away, Be right back) |
Available | |||
| Nimbus Layer (in addition to Teams, according to dependencies described above▲ or below ▼ ) | |||||||||
| Offline Presence check |
► Offline User will not receive Nimbus tasks. |
User is inactive in all MS Teams-based services… AND/OR in Off Duty Profile |
🔎Configurable Distribution Service Settings exception: MS Teams "Busy" or “Away” status ▲can be opted-in, making users Selectable ▼ for Tasks |
||||||
| Service assignment check |
►Off Duty User will not receive Nimbus tasks. |
Active in Nimbus - MS-Teams based Services will distribute to this user. 🔎Individual Active toggles: Each Service has individual “Active” toggles, allowing users to steer availability per Service. |
|||||||
|
On Duty Profile - Contact Center Services will distribute to this user. 🔎 Profiles and Skills: Any "On Duty" type Responsibility Profile allows Contact Center participation. For the user to be "Selectable" ▼ Skills and Responsibilities defined in the profile must match the Service. This is determined by the individual Distribution Policies assigned to the respective Service. | |||||||||
| Conditional Presence check |
❌►Not Selectable User will not receive Nimbus tasks. |
||||||||
| Task count check |
Task Parallelization is enabled for the user. AND user is Available ▲ OR Service configuration says "Busy/Away - Distribute to the user" … AND user has reached tasks limit … AND all the tasks are in non-blocking states. |
||||||||
|
► Task Limit Reached User will not receive Nimbus further Nimbus tasks. 💡This state has lower priority than “Not Selectable” due to MS Teams presence ▲. | |||||||||
| Selectable state |
User can get at least one task User is Available or Service Distribution settings ▲ allow Busy/Away - Distribute |
||||||||
|
✅ ► Selectable User can receive Nimbus tasks. | |||||||||
| Nimbus Task-related states | User currently reserved and blocked by a Nimbus task. Can result in any of the following User States. | ||||||||
|
RONA User flag after not responding to a task, blocked for the next tasks. |
Ringing User is reserved for new task, but has not accepted yet. |
Dialing Out User accepted outbound task, is waiting for destination to accept. |
Connected User has accepted and is now blocked by a task. |
After-Call Work User-extensible timespan to complete work after a call. |
|||||
User State Factors explained
First and foremost, it is important to note that User State factors relate to each other. Reading the table above, relationships are indicated with arrows ▲▼. Expand the items below to learn more about each factor.
MS Teams presence
💡Good to know: Nimbus will always read Teams Presence, never actively change this status. It is upon the user to change their presence actively to signal willingness to take new tasks.
MS Teams presence always forms the uppermost layer for Nimbus for User State validation:
- The presence check must always be passed first. Presence must meet the criteria of the Distribution Service Settings. This can be individually configured per Service, which means that users can be conditionally made “selectable” even while Away.
-
Online users are considered for Nimbus tasks depending on:
- … the Services for which they have a Portal Role assigned AND
- … the Service mapping criteria (Active / Duty State) are met → See below.
- Offline / DND users are not considered. Nimbus will not distribute tasks.
Service assignment & presence
These factors are shared criteria among Services, depending on the Services the users participate in. The Type of Service determines when a task is being distributed to selectable users:
| Advanced Routing and Enterprise Routing | Contact Center |
|---|---|
| Start condition: MS-Teams "Team”-based Services with a fixed pool of team members. Users are signed in within MS Teams | Start condition: Nimbus standalone Services with a dynamically assigned user base. Users are signed in within MS Teams |
|
Advanced Routing and Enterprise Routing consider users selectable once they are set “Active” in the Nimbus UI.  |
Contact Center Services replace the “Active” state with a Duty State as a conditional “is selectable” check.  |
| 💡The “Active” toggle is considered as “selectable” factor. | 💡The “Active” toggle is replaced by the Duty profile. Nimbus distributes according to the Skills and Responsibilities related to the profile. These criteria are defined in each Service's Distribution Policy. |
| Selectable are: The entire “Online” and ”Active" pool of users with in an Microsoft Teams Team is considered as selectable. | Any “Online” Nimbus user can be considered depending on the factors above, regardless of “MS Teams” membership. |
🔎Note: Mixed participation is possible
When users participate in multiple Services, a mix of “Active” toggle and “Duty Profile” can be leveraged by users to steer their participation.
💡Example: A user is “Signed In” in MS Teams and wants to steer presence in the Nimbus UI for multiple Services
| MS Teams Presence | Active Toggle |
Selectable for: Advanced- / Enterprise Routing |
On Duty Profile |
Selectable for: Contact Center |
| Signed in | ❌ | ❌ (not selectable while "Inactive") | ❌ | ❌(not selectable while “Off duty”) |
| Available | ✅ | ✅ | ✅ | ✅ (Distribution Policies apply) |
| Available | ❌ | ❌ | ✅ | ✅ (Distribution Policies apply) |
| Available | ✅ | ✅ | ❌ | ❌ |
| Away | ✅ | ✅ While Distribution Service Settings > Away > "Distributed to the user”. | ✅ | ✅ (Distribution Policies apply). |
| Busy | ✅ | ✅ While Distribution Service Settings > Away > "Distributed to the user”. | ✅ | ✅ (Distribution Policies and Distribution Service Settings apply). |
| DND | ✅ | ❌ (DND is always task-blocking) | ✅ | ❌ (DND is always task-blocking) |
Task count / limit check
Whenever Task Parallelization is enabled for a user, they can get multiple tasks distributed to them. This will happen when the following prerequisites are met:
- Task Parallelization is enabled for the user in their General User Settings.
- The user is “Selectable” according to the presence/mapping factors described above.
- The user is already Parking a task.
- The user is not in any task blocking state. → 🔎See table below, or visit the Task Parallelization page to learn more.
🔎Table: Task blocking states
INC Task blocking states
| Modality ► | |||||||
|---|---|---|---|---|---|---|---|
| Direction ► State Category ▼ |
Inbound |
Outbound |
Outbound |
Outbound with Workflow |
None |
Inbound |
Inbound |
| Incoming | Blocking | Blocking | Blocking | Blocking | Blocking | Blocking | Blocking |
| Dialing Out | N/A | Blocking | Blocking | N/A | N/A | N/A | N/A |
| Connected | Blocking | Blocking | Blocking | Blocking | Blocking | Blocking | Blocking |
| Transferring | Blocking | N/A | N/A | N/A | N/A | N/A | N/A |
| On Hold | Blocking | Blocking | Blocking | Blocking | N/A | N/A | N/A |
| Parked | Non-blocking | Non-blocking | Non-blocking | Non-blocking | Non-blocking | Non-blocking | Non-blocking |
| Unparking1 | Blocking | Blocking | Blocking | Blocking | N/A | N/A | N/A |
| In (Extended) ACW | N/A | N/A | N/A | N/A | N/A | N/A | N/A |
1 Not visible as a dedicated state on the UI. While Nimbus is unparking a session, a “blocking” invitation is ringing in MS Teams, preventing the User from receiving further tasks.
💡Good to know
Once the maximum numbers of tasks is reached, Nimbus will not distribute further tasks to the user.
Even with Task Parallelization enabled, additional factors may prevent the user from getting additional Tasks. Examples are:
- Being in any task-blocking state (according to the table above).
- Being in DND presence, marking the user as “not selectable”. This will take precedence the task limit.
Task-related states
This factor is considered by all Nimbus Services. Nimbus uses these flags to signal why a user is currently “Not selectable”. This is also done to keep a track record for Nimbus Reporting purposes.
Task states
Nimbus these states to make users unavailable for further tasks. For example:
- While already being in a blocking status (e.g. Not Selectable, already busy in a task, in After-Call Work (ACW) or flagged by RONA from not answering a task), no further tasks will be distributed to the user.
- ACW, Connected and Ringing are reported as dedicated states, all other blocking statuses are reported as “Not Selectable”.
- “Offline” in Teams or “Off Duty” in Nimbus are also reported as dedicated User States.
🔎Table: Overview of User States
INC User State Type Table
For Reporting purposes Nimbus tracks User States, which define the ability of a User accept and handle tasks. Below is a table of these tracked states:
Id |
Name |
|---|---|
| 1 | Offline: User offline in MS Teams and thus cannot be selected for Tasks. |
| 2 | Off Duty: User is either in a “Offduty” Duty States or “Inactive” in Nimbus UI. |
| 3 | Selectable: User logged-in MS Teams and available to take Nimbus tasks. → Also see Task Queue and Distribution. |
| 4 | Not Selectable: User is in a MS Teams presence state that blocks task distribution as per Distribution Service Settings. |
| 5 | Ringing: A task has been assigned to an User but not yet been accepted. Can be either incoming calls or when an User is accepting an Outbound Call. Also applies for non-telephony-related modalities like Email, External Task, Instant Messaging etc. |
| 6 | Connected: The User and Customer are in a session together. Also applies when the User is just handling an External Task. |
| 7 | After-Call Work: User is handling After-Call Work (ACW). |
| 9 | RONA: User flagged with RONA state by a non-accepted task. |
| 10 |
Dialing Out: User has accepted an Outbound Call and Nimbus is now ringing the target Customer.
|
| 11 | Task Limit Reached: User has reached max allowed number of tasks assigned. Even if the user state would allow for new tasks, the task limit will prevent further distribution to this User. |
✅ Enabling User State Tracking & Data Privacy
Each time a user changes from one Status to another, a Nimbus Reporting record is written as an historic entry to the database. Transitions will therefore not appear in the UI, but only as timestamp record on each status change.
💡GDPR Data Privacy Opt-In: Tracking detailed User States allows for a time-based analysis of the states of each user. Note that this option generates a lot of additional reporting data that also reveals daily user habits. Tracking of this data must be explicitly enabled via Tenant Administration > Data Privacy in order to be recorded in the historic reporting.
🔍 You can also check for any call status flags (RONA / ACW) in Assistant - both in Nimbus UI or the standalone App.