Session Start/End

A session represents an event in the Nimbus system and is the lowest granular record of the Nimbus reporting/statistical data made available for analysis and reporting both in the Nimbus UI and in the BI platform. It represents a completed transaction in the Nimbus system.

Session Start / End:  All Service / User / Transfer Sessions are reported only when terminated. For example: A workflow Queue Activity "Accepted" Service task must either be handled OR transferred by the Nimbus actors: System, Workflow, User. The workflow then needs to “Disconnect” to end the Service session for reporting closure.

For example, an audio call entering the Nimbus system and going through the “Accepted” and “Disconnected” Workflow Activities of a Service Workflow represents a successful Service Session. If a call goes through multiple workflows, e.g. in the course of an interaction with a customer by multiple services and users, multiple “service” and “user” sessions are created. 

Failed sessions 

Failed Sessions are “technical” Nimbus records and should not influence reporting KPIs, as they usually mean something has gone wrong. Failed sessions are only reported only on Administrative side and not part of statistical reporting. 

Examples are: 

• A stuck call got (forcefully) removed via Admin Operations.
• Nimbus has determined some failure (e.g. infinite loops in the WF) and removed the session automatically.
• Some unexpected Azure or other component outages are leading to irregular session results.

Service Sessions

A Service Session is an interaction of any supported modality or direction with Nimbus Service. Usually it's a parent to user or transfer sessions. Service sessions get created: 

• Whenever MSFT notifies Nimbus about incoming Audio/Video, Instant Messaging or Email conversation.
• When Nimbus gets a notification from MS Power Automate, e.g. on scheduled Outbound Call, External Tasks.
• When a user starts an outbound Call On Behalf from Nimbus UI.

💡Good to know: 

• Failed Service Sessions are not included into Nimbus Portal UI, OData feed (and therefore, Power BI Nimbus template).
• However they can be be included in Admin UI reporting (e.g. the Operations page) as they usually point to technical issues.

User Sessions

A User Session is an attempt to connect to a Nimbus User (also known as “Agent” in some context). User Sessions are supported for any modality and direction and they cannot exist without parent Service Session. It doesn't matter if this attempt to connect to a user was successful or not, regardless of the reported outcome it's still a user session.

💡Good to know:  

• Successful User Sessions from a failed parent Service session are
  • still reported on Portal UI (e.g. My Sessions, My Overview, Service Reporting)
  • not reported in Power BI
• Failed User Sessions themselves are neither included into Nimbus Portal UI, OData feed and Power BI reports.

Consultation

Consultations  - e.g. inviting a 3rd expert during a call - are a subset of User Sessions. This implies, that each Consultation is technically also a User Session. A consultation starts when consultation attempt is started when a user uses the “Consultation Call"  button in Attendant Console and ends when Consultation is ended.

Transfer Sessions

A Transfer Session is an attempt to transfer either a Service or User Session to another Service, Nimbus User or external target (like a PSTN phone number). This implies, that each Transfer Session must have a parent (Service or User Session) and also a transfer destination. 

Transfer Session usually start when transfer attempt is started, e.g. when User pressed Transfer button on the UI, and ends when the attempt is ended, e.g. Destination has declined or accepted the invitation.

💡Good to know:  

• Transfer Sessions are not reported to Nimbus Portal or Admin UIs.
• Successful Power BI reporting of Transfer Sessions depends on the parent session:
  • if a parent Service Session failed (in case of transfer by WF) then Transfer Sessions are not returned
  • if a parent User Session failed (in case of transfer by User) then Transfer Sessions are not returned. However…
    • …if the parent User Session didn't fail, but parent Service Session has failed, the User Session itself - and in extension the Transfer Sessions - will not be be returned as well.
• Following these rules, only successful Transfers (on Service Session level) are part of BI Reporting. Failed Transfer Sessions are not included into Power BI reports.

Unified Sessions

A Unified Session represent the business concept of an End-2-End interaction (for example and End-2-End call). Its main goal is to combine all (read: multiple) Nimbus Sessions for a given interaction with a Customer and is set for any modality and direction. Since an End-2-End interaction can comprise one or more sessions, a Unified Session provides an aggregated view of the KPIs coming from the underlying sessions that make the End-2-End interaction.

The best example is an Inbound audio call: A customer calls the Contact Center, the call is accepted by the first Service and is then transferred to another Service (by Workflow, or by a user User after first accepting the call). In this case, two different Service Sessions will be created, such Service Sessions will be combined under the same Unified Session.

💡Good to know:  

• The common denominator between Unified Sessions, Service Sessions and User Sessions is the UnifiedConversationId. 
• Since Unified Sessions can include one or more service sessions or user sessions, the Unified Session KPIs represent an aggregation of the underlying sessions. When multiple non-cumulative attributes apply, for example outcomes of different sessions or start and end timestamps, a logic is applied to select the most appropriate attribute to show (e.g. the outcome of the very last session or the start time of the first incoming session). These details are described in the section dedicated to Unified Sessions in the Nimbus Reporting Model page.