The "Sessions List" page lists concluded sessions and the related data – e.g. the amount of involved user sessions, the task direction, task type and session results.
Preconditions
Service Owner / Supervisor Portal Roles: This page is visible to service supervisors and service owners only. Data shown is limited to service viewing of the currently signed-in user and dates back a maximum of 30 days.
🔍 To get access to further data, review and assign User Administration → Roles tab. Refer to User Roles for further details on each role.
☝ 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. 🔍 Lookback 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. |
| 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 Sessions | A filterable, sortable, and expandable list of service sessions. Shows the following columns:
💡 Entries can be expanded to show the rows of user sessions related to this service session. Shows the following columns:
|
Session Filtering
A large amount of Historical Sessions can be filtered by various criteria.
💡Note that filters only affect the listing in the “Historical Sessions” widget. The top row of widgets will always show a static 30 days lookback.
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. |
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 data shown in the popup is the same that was made visible on My Sessions at the point of the incoming call:
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. |
| Codes & Tags |
🔎 “Not available” when session data was not stored. More details in the infobox below. |
| Session Details |
Session detail parameters (if provided by an external CRM, User Directory), as configured in Extensions Service Setting. 💡Session Details can be copied by clicking the copy icon (appearing on hover). 🔎 “Not available” when session data was not stored. More details in the infobox below. |
| 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. |
Context Data (non-) availability
- Only base call metrics (Date, Duration, IVR and Connection times, Name of Service) are historically stored for each Service Session
- Context data, like Codes and Tags need to be provided by the task-receiving user. If not provided, these fields will be “Not Available”.
- Session Details (e.g. Parameters and System Fields) are provided during live session, via Microsoft Power Automate Connector at the point of the incoming task. Refer to our Power Automate Use Cases list for various integration scenarios.
☝Historical storage of context data (and visibility in historical session details popup) is determined by Extensions Service Settings. This applies for all of the aforementioned context data and session details.
Learn more about this Context Data storage setting…
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 not be stored by Nimbus.
As a result:
⮑ 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 via Nimbus Power Automate Connector) may 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 Historical Sessions). The setting must therefore be enabled by a service owner (Opt-in).
💡Enabling this setting has no retroactive effect, meaning that only data after enabling this setting will get stored.
🤔What happens when I enable this?
☝ Task information / Session detail data is stored per service session on call termination (transfer by workflow or user).
- The following is stored per session in both My Sessions and Historical Sessions
- Custom (user created) Parameters
- System Fields and Parameters (both “Custom” and "System" parameters like call id, service upn, etc.)
- On historical (concluded) sessions within My Sessions
- ... the "Embedded Context widget" will resolve 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.
☝ Default "My Session Parameters" user data is not stored as it is 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/killed calls.
- After 30 days the data is cleared. This also happens when either the service or tenant is being unprovisioned when Uninstalling Nimbus.
☝ Best Practice: If you wish to store 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).
🔍 Whitepapers: You can also learn more about the data retention policy in our whitepapers, available in the Documents section.