This page serves as an example to analyzing Nimbus Reporting sessions, by applying the Nimbus Reporting Model to various call scenarios. The goal is to give some practical examples and highlight some learnings around the Nimbus reporting model under different viewpoints.
Session Outcomes
INC Transfers and Nimbus Reporting Outcomes
🔎Rule: Last Outcome
 Rule for Nimbus Reporting > Outcomes & Sessions List Task Results: The overall Service Session outcome in a “Transferred-by-user Scenario” is set according to the outcome of the last User Session.
| Transfer Scenario | User A - Session 1 Outcome | User B - Session 2 Outcome | Expected Service Session Reporting Outcome1 |
|---|---|---|---|
| User A blind3 / safe transfers to Internal Destination B, which accepts | Transferred Internally | Accepted | User Internal Transfer Successful |
| User A blind3 transfers to Internal Destination B, which does not respond (ignore) | Internal Transfer Failed | Cancelled | User Internal Transfer Failed |
| User A safe4 transfers to Internal Destination B, which rejects, Customer terminates afterwards. | Accepted | Declined | User Accepted |
| User A transfers to Destination B Voicemail 2,5 directly | Transferred Internally | None, as no User Session is created for user B.2 | User Internal Transfer Successful |
| User A starts a Consultation Call to a Nimbus Service | Transferred Internally | Accepted | User Internal Transfer Successful |
| User A starts a Consultation Call to a PSTN (non Nimbus) number | Transferred Externally | None, as no User is tracked as long as they are not part of Nimbus. | User External Transfer Successful |
1 See Nimbus Reporting Model >  Static Dimensions > “User Session Outcomes”
2 Voicemail and Reporting: Any direct "Transfer to Voicemail" Actions via Attendant Console are not creating a new User Session or any related User State checks for the Nimbus Reporting Model.
3 Blind Transfer behavior: When the destination doesn't accept – and has Voicemail or any other forwarding activity enabled – the transfer will not reach Voicemail nor the forwarding target. This is expected Contact center behavior and avoids the loss of calls.
4 Safe Transfer / Voicemail behavior: When the destination doesn't accept - and has Voicemail enabled - the transfer will NOT reach the Voicemail. This is expected Contact Center behavior to avoid a potential call loss.Â
5 Disabled Voicemail: Nimbus cannot check ahead if voicemail is enabled for a user, but the “Transfer to Voicemail” UI element is always shown. Also refer to the “Transfer to disabled Voicemail” limitations.
đź’ˇLearnings:Â
- General Rule: The reporting session outcome is derived from the last child session.
- The outcome of a reporting session can be different depending on the call flow or transfer scenario. For example, in a multi-service or user transfer scenario, the actors and transfer directions can also affect the result, as reflected by wording like internal, external, by users, by workflows.
- User sessions with individual outcomes in Nimbus reporting are only created when the target user was added to the User Administration, and thus “known” to Nimbus.
🔎Also see: Nimbus Reporting Model and Static Dimensions.
Task Direction
For a reporting example on a outbound call → transfer scenario, let's imagine the following
- 3 Services: A, B, C
-
Participants:
- Customer
- User 1 from Service A
- User 2 from Service B
| # | Input | Service A | Service B | Service C | Details |
|---|---|---|---|---|---|
| 1 | User 1 receives an Outbound Call task, calling a Customer on behalf of Service A. | Outbound | Â | Â | Â |
| 2 | Customer accepts | Outbound | Â | Â | Â |
| 3 | User 1 starts transfer to Service B | Outbound | Inbound |  | 💡The new task direction is now “Inbound” for the remainder of the call flow. Other services will treat the task like any regular “inbound” task. |
| 4 | User 2 accepts | Â | Inbound | Â | |
| 5 | User 2 transfers to Service C | Â | Inbound | Inbound | |
| 6 | Customer hangs up | Â | Â | Inbound |
đź’ˇLearnings:Â
- General Rule: When scheduled as outbound task1 in Nimbus queue, the task direction is reported as “outbound”.
- In a multi-service transfer scenario, where the first service handles the outbound task, and then transfers to another service, the task direction on the receiving service will be set to inbound, e.g. treated like any other regular incoming call. Subsequent service transfers will also treat the new task as “inbound”.
🔎 Also see:Â
- 1 Outbound tasks must be created via Power Automate Connector: “Outbound Call” Flow Actions . See Use Case - Creating Nimbus Outbound Calls from a List of Scheduled Tasks.
- Related concept pages: Outbound Call / Call On Behalf / Static Dimensions (Task Type / Direction)
Transfers
- 2 Services: A, B
-
Participants:
- Customer
- User 2 from Service B
- User 3 is a single Nimbus user without a service, e.g. an expert
| Â | Â | Nimbus Reporting Model Session Outcomes | ||||
|---|---|---|---|---|---|---|
| # | Input | Unified Session | Service A Session | Service B Session | User 2 Session | User 3 Session |
| 1 |
Service A transfers a Customer to Service B via worklow  |
Ongoing (No outcome) | Workflow Internal Transfer Successful | Â | Â | Â |
| 2 | User 2 from Service B accepts and safe or blind transfers to User 3 | Â | Ongoing (No outcome) | Ongoing (No outcome) | Ongoing (No outcome) | |
| 3 | User 3 accepts and blind transfers to an external PSTN | Â | Ongoing (No outcome) | Transferred Internally | Ongoing (No outcome) | |
| 4 | External PSTN does not respond | User External Transfer Failed | Â | User External Transfer Failed | Â | External Transfer Failed |
đź’ˇLearnings:Â
- General rule: Users must be known. Transfers to users in your O365 directory that are not defined in Nimbus will work, but are not reflected as a separate reporting session. In the example above there would be no “User 4” session for any external users unknown to Nimbus.
- The last service session outcome determines the unified session outcome. This continues on even for user sessions outside of a service context, as long as the user is known and defined in the User Administration.
- Nimbus keeps tracking the session for external PSTN transfers until the number either responds or  - in this case - times out.
đź’ˇ Good to know: Nimbus can also track calls made directly to user, which requires Direct Call Reporting to be enabled.
Consultation Calls
- 2 Services: A, B
-
Participants:
- Customer
- User 1 from Service A (Service desk)
- User 2 from Service B (Expert consultation)
| Â | Â | Nimbus Reporting Model Session Outcomes | ||||
|---|---|---|---|---|---|---|
| # | Input | Unified Session | Service A Session | User 1 Session | Service B Session | User 2 Session |
| 1 |
Customer calls service A and will be connected to User 1.  |
 |  | Accepted |  |  |
| 2 | Since user 1 can't help the customer directly, service B gets involved in a Consultation Call. While the call is made, the customer is put on hold. |  | Consulted |  |  | |
| 3 |
User 1 gets connected to user 2 from Service B, the customer remains on hold. After consultation with user 2, user 1 puts the customer off hold to inform them, then transfers to user 2. |
User Internal Transfer successful |
Consulted Transferred |
 |  | |
| 4 | User 2 accepts, retrieving the customer automatically. The session continues until either party leaves the call. | User Accepted | Â | Â | User Accepted | Accepted |
đź’ˇLearnings:Â
- Nimbus uses reporting events (such as Accepted, Consulted, Transferred) to mark start and endpoint to various tracked durations. In this example we focus on
HoldTime, which is is included in theConnectedTime. - The timing durations are tracked for each service and user session individually. This is done to get detailed timestamps where “On Hold” overlaps between Service A and B, or to accurately discern how long any participant was put "on hold".Â
- Unified sessions further distinguish by adding a
InitialCaller-prefix to track the customer point of view of these durations. - In the Nimbus Reporting Model there are data objects with
InitialCaller-prefix which track additional aspects such as:InitialCallerConnectedTimeInitialCallerHoldCountInitialCallerHoldTimeInitialCallerIVRTimeInitialCallerQueueTime
🔎 For more details, consult the “Unified Sessions” table on the Facts - Columns and Data Types page.