For its Reporting Model, Nimbus distinguishes sessions by various user state factors: Teams Presence, Duty State, Task Selectability, and User Status flags. A change in either factor has influence on the others, either in being a requirement or in a co-dependency.
Factor | Precondition(s) | Tracked User State relevant to Nimbus | ||||||
---|---|---|---|---|---|---|---|---|
Teams Layer | ||||||||
Presence in MS Teams |
✅ Online – including status "Busy" or "Away" (individually defined per Distribution Service Settings) |
Online MS-Teams based services will distribute when "Active". |
Online and set "Active" in Nimbus MS-Teams based services will distribute. |
Online but Busy/Away in Teams and set "Active" in Nimbus Conditional: Determined per each service's Distribution Service Settings aser can either be selectable ↓ or not. |
||||
Nimbus Layer | ||||||||
✅User is online and has any "On Duty" responsibility profile selected. |
Off Duty Being in an "Off Duty" profile prevents any Contact Center participation. |
On Duty Any "On 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 selectable |
“In Time available” to perform tasks in Nimbus: ✅Online in MS Teams. |
"Selectable" This includes Busy/Selectable and Away/Selectable |
"Non-Selectable" state, either because: … User is not available either due to the MS Teams Presence ↑ OR … … set "inactive" for all Nimbus teams OR … ... any existing or previous Status Flag ↓ marks the user as “Not Selectable” |
|||||
User Status flags |
✅ User is currently reserved and blocked by a Nimbus task.
|
Not Available Reason Requested from “Idle / Away” users during a task distribution. |
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. |
Connected User has accepted and is now blocked by a task. |
ACW User-extensible timespan to complete work after a call. |
USER STATE FACTORS ARE CO-DEPENDENT
💡 It is important to note that these user state factors depend on each other. The table above should be read vertically from “top to bottom and back".

🔎 In the following we're explaining each factor and its related co-depencenies:
Factor 1: MS Teams Presence
This factor is considered by all Nimbus services. Every user in MS Teams can be considered for Nimbus when part of a service.
- The MS Teams presence must meet the criteria of the Distribution Service Settings. This can be individually configured per service.
- Offline users are not considered to be in any Duty State. Nimbus will not distribute tasks.
-
Online users are considered for Nimbus tasks depending on:
- … the services they are part of and
- … the Nimbus features (e.g. licenses, modalities settings for the user.)
🔎It is noteworthy that “MS Teams presence” marks only the first layer of consideration for Nimbus. When users participate in multiple services, each service can individually regard them as “selectable” or not. Learn more about this below.
Factors 2 & 3: In Nimbus Duty State / Task selectability
These are shared criteria among services. Task Selectability in Nimbus is steered based depending on the Types of Service the user participates in.
Advanced Routing and Enterprise Routing | Contact Center |
---|---|
MS-Teams "Team”-based services with a fixed pool of team members. | Nimbus standalone services with a dynamically assigned user base |
Advanced Routing and Enterprise Routing consider users selectable once they are set “Active” in the Nimbus UI. 💡The Duty State is a Contact Center exclusive feature and not considered for these services. |
Contact Center services replace the “Active” state with a Duty State as a conditional “is selectable” check. Evaluating that profile, Nimbus evaluates user responsibility and distributes calls conditionally based on Skills and Responsibilities. These criteria are defined in each service's Distribution Policy. |
The entire “Online” and ”Active" pool of users with in an “MS Teams” Team is considered. | Any “Online” Nimbus user can be considered depending on the factors above, regardless of “MS Teams” membership. |
🔎When users participate in multiple services, each service can “flag” users with a blocking status as they handle tasks. Learn more about this below.
Factor 4: User Status (Flags) and Reporting
These are shared criteria among services.
- While “online” in Teams and “Active” and "On Duty" in Nimbus, a user is in principle “Selectable” for tasks by any service, in any modality, unless they are in a blocking status in Nimbus.
- The “online” status in combination with “Busy” or “Away” in Teams may be reported as either “Selectable” or “Not selectable” state, depending on the configuration set under “Conversation Distribution” for the specific service.
- Blocking status in Nimbus always takes precedence over any "Selectable" state; therefore, while being in any blocking status (e.g. Not Available, already busy when connected or in a task, in ACW or flagged by RONA), no new task 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 reported as dedicated user states.
User State Reporting and Data Privacy
Each time a user changes from one status to another a user state, a record is completed and written into the database. Only completed states are tracked in the Nimbus Reporting, therefore the current user state (e.g. “as of now”) will not appear in the database until the user has switched to the next user status.
Considering that a user status can change frequently throughout the working day, the User States data can become very large when looking at multiple dates.
💡GDPR Data Privacy Setting: detailed user states data allows for time-based analysis of the states of each user, e.g. in Power BI. Tracking of this data must be explicitly enabled via Tenant Administration > Data Privacy in order to be recorded in the historic reporting.