The "Sessions List" page lists concluded sessions and the related data – e.g. the number and duration of involved User sessions, the task direction, task type and final session results.
Preconditions
Service Owner / Supervisor Portal Roles: This page is visible to Service Supervisors and Service Owners only. Data shown is limited to services of the currently signed-in user and dates back a maximum of 30 days. Roles are granted by an Administrator via User Administration > Roles tab.
☝ First-Time Data Operation: When opening the "Sessions List" view for the first time, data might not be shown yet due to recalculations occurring in the background. We recommend to wait at least 24h to get a comprehensive and correct dataset.
Overview
The page shows the following data in various widgets.
| Widget | Description |
|---|---|
| Session Result |
The total # of sessions and their task result, shown as a donut chart:
💡 Mouse over for tooltips with absolute numbers. Click on the legend to filter out entries. |
| Sessions |
The total of sessions per day as a bar chart: 💡 Mouse over for tooltips with date and absolute numbers. 🔎 Note that Session lookback scope is restricted to a maximum of 30 days. For a comprehensive historical data set, use the Power BI OData connection and our Power BI Template. More info on session data scope and retention times can be found on our Nimbus Reporting concept page. |
| Session Type |
The relative amount of sessions, distinguished by modality:
💡 Mouse-over tooltips will show absolute numbers. You can click on the legend to filter out entries. |
| Session Direction |
The relative amount of sessions, distinguished by session direction, shown as donut chart:
|
| Historical Sessions1 | 💡A filterable, sortable, and expandable list of Service sessions. Shows the following columns:
 💡Entries can be expanded to show the rows single of User sessions related to this Service session. Shows the following columns:
|
Related Pages
1 A new Service (and/or) multiple User sessions are created per Customer interaction. For more information on how Nimbus creates and structures session data, refer to Nimbus Reporting.
2 Note that this refers to the Service-related Voicemails, showing Adaptive Cards in a channel as set up via Modalities Service Settings. Transfers to single User Voicemails are possible via Attendant Console, but not signaled in this view.
3 Customer Identification relies on external systems using the Nimbus Power Automate Connector. If Nimbus has no further details available, the next best System-level identification is shown, e.g. a PSTN number or a 0365 ID of the calling Customer. This column also depends on the Customer's choice to contact a service (e.g. a Chat will use UPN while
Session Filtering
A large amount of Historical Sessions can be filtered by various criteria. The following filters can be applied:
| Filter | Description |
|---|---|
| Direction | Inbound, Outbound, None → See "Session Direction" widget above. |
| Initial Modality | The modality used to contact the serve (e.g. via Call, Chat, External) → See "Session Type" widget above. |
| Date & Time | Narrows down sessions by date (mm/dd/yyyy) and time (hh:mm) within the range specified. → Filters the "Date & Time" column. |
| Duration | From-to-Range (hh:mm:ss) → Filters the Session "Duration" column |
| Opening Hours | Filter sessions by Opening Hours active at the point of the task. |
| Queued | Show only tasks that were queued (true) or not (false) |
| Result | Filter session results as per Nimbus Reporting Model > "Service Session Outcomes" |
| Source | Caller, PSTN number. 💡 Search starts at entering 3 characters / numbers or more. |
💡Note: Filters only affect the listing in the “Historical Sessions” widget itself. The top row of widgets will always show a static 30 days lookback.
Session Details Popup
The session details popup shows call metrics, Users involved, Codes, Tags, Session Details.
|
💡 You can access session details by clicking the icon on a Historical Sessions entry:  |
 |
The following properties are shown:
| Area | Description |
|---|---|
| Customer information |
Shows the calling Customer name. The following information is shown:
|
| Result | Call session conclusion (Accepted, Declined, Cancelled (by caller), RONA). |
| First Accepted User | The first Nimbus User that took the call. 💡 Note that further → User Sessions are created for each internal transfer. |
| First Codes & Tags4 |
Codes and Tags that were added by the first task-accepting user. 💡 Any further Codes and Tags are part of the Nimbus Power BI Template. The selection that was available to the User during this Session is configured in Extensions Service Settings. |
| Session Details4 | Session detail parameters (if provided by an external CRM, User Directory), as configured in Extensions Service Setting. |
| Date & Time | The date and time at which the session took place. |
| Duration | Total time of the Service session. |
| Service | The called Service. |
| IVR Time | Caller's time spent in IVR. |
| Queue Time | Overall time the caller spent in the queue. |
| IVR After Queue Time | Time spent in IVR after a queue (if any). |
| Connected Time | Total time caller and User were connected. |
| User Sessions |
💡Each internal transfer (within the same Service) creates a new User session as per Nimbus Reporting Model. 💡If there were no User Sessions, the message No records available is shown. 💡A transfer between Services starts a new Service session and thus a new historical session details entry. |
4 Context Data: Visibility in Historical Sessions
💡 The data shown in “Details” popup is the same that was made visible on My Sessions during the ongoing session. Note that data may NOT be shown based on individual Service settings and User factors:
- By default, only base call metrics (Date, Duration, IVR and Connection times, Name of Service) are historically stored for each Service Session. This is a baseline of data recorded in System Fields and Parameters.
- Codes and Tags are transferred as part of the Service Context Handover between multiple User sessions. They need to be provided by the task-receiving User, e.g. via My Sessions or Assistant as conclusion of a Nimbus task. If not provided, these fields will be “Not Available”.
- Further Session Details (e.g. Custom Context Parameters and additional Customer-Context) are provided during a live session, e.g. via Microsoft Power Automate Connector at the point or during an incoming task. Refer to our Power Automate Use Cases list for various integration scenarios. → Also refer to the storage settings below to learn if and when these details are shown in the Sessions list.
Context Parameter Storage and Transfer Settings
☝Important: Both storage and transfer of Session Data (Including Context Parameters) determine if you will see any details in the Sessions list. These options are individually defined by each Service's Extensions Service Settings.
Learn more about Context Data storage…
INC Store Context Data
GDPR After a service task has concluded, any historic session and customer context data – e.g. as shown in the My Sessions widgets – will by default not be stored by Nimbus.
While disabled:
⮑ the "Session Details" of any historic task records will show “Not Available” instead within My Sessions and Historical Sessions.
⮑ Previous custom Parameters / and Conversation Context items (e.g. Customer details or URLs dynamically retrieved and formed via Nimbus Power Automate Connector) will not resolve or open correctly anymore.
This storage behavior can be changed by enabling the “Store Conversation Context Data” in Extensions Service Settings:
☝ Note that the “Store Conversation Context Data” option is disabled by default as potentially sensitive caller data can appear in historical records and seen by Administrators (e.g. via Sessions List). Therefore…
- … read the consideration below to understand its effects.
- … note that this setting has no retroactive effect, so only the data collected after enabling the feature will get stored for the retention period.
- … note that the setting must be enabled individually per service (OPT-IN).
🤔What happens when I enable this?
☝Task information / Session detail data is stored per service session on call termination (either transfer by workflow or user).
- Within the UI of My Sessions and Historical Sessions
- Custom (user created) Parameters
- System Fields and Parameters (both “Custom” and "System" parameters like Call ID, Service UPN, etc.)
☝ Restrictions on concluded sessions (e.g. within My Sessions) apply as follows:
- ... the "Embedded Context widget" will resolve with the currently configured URL with a previously saved call information. This means that also historic sessions will use the link currently configured in the Extensions Service Settings .
- ... the separate "Open Context" link remains clickable if at least one Conversation Context URL is currently configured.
- ... the "Session Details" widget will still show Custom and Customer parameters if available.
☝ Not stored (regardless of setting) are:
- Default "My Session Parameters" user data is not stored as it is always retrieved dynamically from the internal user directly of your Tenant.
🤔What happens in service transfer scenarios?
Nimbus always stores live context on transfer to services (either initiated by workflow or user). The "Store Conversation Context Data" option will have no impact there.
☝ However, enabling the "Store Conversation Context Data" setting will cause such live context data to be stored as historical record after call termination. This also applies on each transfer between services, creating a historical record entry for each service that has the setting enabled.
In an example transfer scenario this may cause historical data to “accumulate” between services, as data gets updated and appended.
Example - Transfer from Service A to B to C:
| Parameter | Service A ► transfer to | Service B ► transfer to | Service C |
|---|---|---|---|
| Customer Name | John Doe | John Doe | John Doe |
| Spoken Language | German | <Not Relevant> | <Not Relevant> |
| Gender | <Not Relevant> | Male | <Not Relevant> |
| Ticket ID | #1111 | #3151 (overwritten Ticket Parameter) | <Not Relevant> |
| “Store Conversation Context Data” enabled | ✅ | ⬜ | ✅ |
| Stored Historical Sessions data shown | John Doe (1) German Not used #1111 |
John Doe (1) Not available (not stored) Not available (not stored) |
John Doe (1) German (from Service A) Male (from Service B) #3151 (from Service B) |
(1) The user name will always be resolved from a UPN / PSTN when it was found within the existing O365 user directory.
🤔How long is data being stored?
Caller info is updated on a “terminated” workflow Trigger Events and stored for a maximum of 30 days for the last available service session (in case of transfers). Conversation Context data will also be stored for failed, aborted or “killed” calls.
☝ Note: After 30 days the data is cleared. This also happens when either the Service or Tenant is being unprovisioned (removed from Nimbus Clusters) while Uninstalling Nimbus.
🔍 Whitepapers: You can also learn more about the data retention policy in our whitepapers, available in the Documents section.
⮑ Customer-Side Backup responsibility: If you wish to store mission-critical or personal session data permanently, you need to do so during an active session and within a system of your choice (e.g. a CRM or Database).
Learn more about Context Transfer…
INC Context Settings
As a Nimbus session gets transferred between multiple Services and Users, related System Fields and Parameters automatically carry over. In addition to this, a separate Setting allows to steer if additional Custom Context Parameters should be kept during a transfer from this Service to Users as well.
☝Note that the “Keep Custom Context Parameters on transfer” option is enabled by default for both Services (currently fixed) and Users (optional).
🔎 Custom Context Parameter Transfer Settings
The following Diagram is meant to illustrate the effects of context-related Service settings.
- Each Service can steer these settings individually. This means that Session Data storage and handover settings from a Service A are in effect until a new (receiving) Service B decides to handle the (received and potentially updated) data differently.
- Assuming your starting point is a Service A:
- Call Data & System Data will always transfer to Services and User.
- Custom Context Parameters will always transfer to Services.
- Custom Context Parameters will only transfer to Users if enabled on the originating Service. If toggled off, they will be nulled/reset to defaults.
-
The Nimbus Power Automate Connector can react to various Trigger Events (e.g. Workflow Started, Parameter Updated, Connected to User).
- By doing so, parameters within a specific scope (Service Session or User Session) can be updated, anonymized, or cleared.
- In the Sessions List this may result in different parameter values being shown for each interaction, as each session can have their context updated via separate Flow Actions.
