The concept of "Context Handover" refers to the process of transferring an ongoing Customer Session from one Nimbus actor (User, Service) to another. This process is crucial for maintaining seamless communication and ensuring a consistent quality of service.
Context Definition
INC Context Definition
In a modern Call Center environment the term “Context” can have a very wide meaning and be interpreted differently by various stakeholders. A Business Analysist has different expectations on context as an individual Service Owner managing a team, or an individual Specialist (Agent) handling the tasks.
💡Good to know:
To keep it simple for the following Nimbus definition:
- All “Context” in Nimbus is part of “Session Data”.
- During an existing Session, Nimbus creates, updates, and stores Session Data in System Fields and Parameters.
- Whenever a Nimbus Service or User is involved, a new Session will be created to store all “Session Data”, including the Context.
Context and Session Data
During a Session lifetime, Session Data (including Context Parameters) get updated by either the Nimbus System itself or external actors by leveraging the Nimbus Power Automate Connector. This allows to connect to external sources (e.g. a CRM or Ticketing System) to add, display or update rich context during ongoing Nimbus session.
INC Session Data Definition
All Session Data (stored in fields and parameters) are treated equally in a large JSON object. In order to get a clearer grasp on its structure, it is therefore helpful to define:
- … the type of data for differentiation, …
- … the purpose of each data object and what it consists of, and …
- … which actors accessing or updating the data during an ongoing session.
| Type of Data | Consists of | Purpose | Actors |
|---|---|---|---|
| Call Data | Customer Identification Data | Basic Customer Identification (Name, PSTN, SIP, UPN). |
|
| Customer Custom Fields | Additional Context on a Customer. | ||
| System Data | Service, Customer, User data fields. | Identify Caller, Service, and Users to manage a session. Usually kept up-to-date automatically by Nimbus. |
 Nimbus |
| Custom Context Parameters |
|
Handling parameters that are critical for Task routing (e.g. Queue Time, IVR choices, Customer Priority). They are “custom” placeholders for any Service Team requirement which is not already covered by the other types of data. |
|
| Address Book Fields | Address Book fields of internal or external contacts. | Used to extend the search capabilities for Nimbus UI, e.g. within Attendant Console. |
Power AutomateViewpoints on Context
General Context Questions
To better understand which data provides the best context in a given situation, it helps to distinguish context data by viewpoint. Nimbus structures and stores some Context (e.g. Call and System Data) as part of its Reporting Model to allow clear attribution to questions like:
-
WHENdidWHICH CUSTOMERcallWHICH SERVICE? -
WHEREwas the callTRANSFEREDto? -
WHICHNimbusUSERStook the call? -
WHATwas theRESULTof this call?
This Nimbus Reporting approach reflects these Viewpoints with it's Session structure. For example:
- Unified Sessions - A combination of multiple Service and User Sessions as a given interaction with a Customer.
- Service Sessions - A Customer interaction with a Nimbus Service, e.g. IVR and Queue.
- User Sessions - A Customer interaction with one or multiple Nimbus User (Agents).
On that matter it is important to now that Context can also be added, updated and stored on each Session level, by leveraging the Nimbus Power Automate Connector. In some cases, Nimbus automatically provides certain context automatically by itself, e.g. in the form of “System Data”.
Adding Context to a Session
During an ongoing session this System Context Data can be “enriched” with Custom Context Parameters and Fields to be displayed in (or intentionally hidden from) the user's UI, as the customer interaction is ongoing. A typical Use Case would be a Service Manager or IT Administrator connecting to external systems to help Agents with additional Parameters to be shown on the UI.
This allows to tackle user level questions, such as:
-
ON WHAT TOPICdid the customer callWHICH INITIAL SERVICEabout? -
HOW LONGhas the call been ongoing, and how manyPRIOR TRANSFERS? -
WHO ELSEhas spoken to the customer before? -
WHAT FURTHER INFORMATIONwas provided in prior calls? -
HOW CAN WE HELPin the best way, given the current situation?
Showing and handing over the right context at the right time is a challenge. The following table is therefore meant to show considerations depending on the Viewpoint.
| Viewpoint | Core Focus | Context Handover considerations: |
|---|---|---|
| Session |
Comprehensiveness: Multiple transfers between services and users require tracking of multiple task results in Sessions List as well summarizing combined KPI metrics and data collected by different agents. |
Context to evaluate customer handling efficiency:
|
| Service | Scope: Some customer details may be relevant for Service A, but should not be disclosed to Services B and C. |
Context that helps with individual Service efficiency:
|
| User | Correctness: Getting the appropriate information into the hands of the right user. |
Context to allow Agents to work efficiently:
|
Configuring Nimbus Context in the UI
💡In summary: It is noteworthy that the Context shown in the UI is “Viewpoint-agnostic”, so it can consist of Service & System Data, mixed with Customer Details and (manually enriched) Custom Context Parameters. The average Nimbus Users will not necessarily see where this information is originally coming from – they only care that is presented up-to-date and correctly.
Nimbus may show Context in different UI areas, either as popups, widgets, or sidebars. The UI approach for Context however is primarily focused My Sessions, Assistant and Attendant Console, where live interactions between Service User and Customers occur.
🔎 The Configuration details and their UI examples are further explored within the Nimbus Configuration > Conversation Context.
How to Transfer Context
Nimbus primarily uses its available data sources (stored in System Fields and Parameters) and updates them at certain Trigger Events which can also leverage the Nimbus Power Automate Connector to perform Flow Actions to update the context during, mid, or after a session.
Outside of the Connector interaction, it is important to note that certain System Data will always be refreshed and cannot be configured via settings or manipulated. System data can only be opted to be “shown” in the UI, while own Custom Context Parameters can be.
✅To initiate a Custom Context transfer, two conditions need to be met:
- The Extensions Service Settings need to be configured by the Service Owner, which determines which context gets shown and/transferred.
→ Also check the follow-up considerations below. - During a call, the initial Nimbus user handling a customer call needs to perform a Safe Transfer / Blind Transfer to hand over the session and related (context) data to the next service or user.
Context Data Transfer Settings
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.
✅Follow-Up Considerations: Context Configuration and Power Automate
Large portions of Nimbus Session Data (System Fields and Parameters) as well as the Administrator defined Custom Parameters can be influenced by the Nimbus Power Automate Connector.
Service Configuration: Custom Roles can be assigned to users other than the Tenant Admin or Service Owner to delegate the Service configuration within the Extensions Service Settings, including the related Conversation Context and Parameters setup, as well as their use within Workflows.
Power Automate Flows: Any context-related updates in the Nimbus UI require Power Automate, and thus a user with a valid Power Automate Role and according license. Certain levels of expertise are required to ensure Power Automate Use Cases involving any Custom Parameter updates are implemented correctly - e.g. by updating, anonymizing, or scrubbing data prior to a Service-to-Service or User transfer.
Transfer Sessions: User Experience
From a Nimbus user perspective, the transferred session (and related Context Handover) experience only differs in slight points:
- Receiving user will get ALL the originating Service Settings. The receiving user will be temporarily treated like they are an “asset” of that service, meaning:
- My Sessions will show the task as if the user is part of that service.
- Codes, Tags, and Call Details are all shown and available to the user. Conversation Context is shown and opened in the same way (e.g. as separate tabs, widgets).
- After-Call Work (ACW) from the service will apply.
- The Historical Sessions List will have slight changes:
- "Codes & Tags" section will show “First Codes & Tags” to indicate that multiple users were able to select these elements1.
- Session Widgets will show combined Connected Time.
- "Accepted by" User fields (e.g. in Operations) will show the first accepting User.
1 🔎Further details can be inspected in the Nimbus Power BI Template > Tags and Codes.
Known Issues and Troubleshooting
INC Transfer Limitation List
💡In the following we list all known Transfer limitations, either by design or external circumstances.
Context Handover during Transfers
INC Context Handover Limitations
The Transfer of Custom Context Parameters works within Attendant Console. Currently Supported Scenarios are:
- Attendant - Safe Transfer → To User or Service
- Attendant - Blind Transfer → To User or Service
- Attendant - Consultation Call → Session Transfer not supported.2
| Transfer | …to User | …to Service |
|
By User on |
✅ Call Data + Customer.Custom Fields ⬜/✅ Custom Context Parameters only if enabled in respective Service Settings. |
✅All Call Data + Custom Fields, System Data and |
| By Service… | ❌ No Context gets transferred.1 |
✅All Call Data + Custom Fields, System Data and |
CONTEXT TRANSFER LIMITATIONS
The following Context Transfer limitations are known. We are actively working to improve this in a future update.
- 1 Workflows > “Transfer” Workflow Activity: A Custom Context Transfer from within a Service workflow to any target will not work.
-
2 No Transfer out of Conferences: All MS Teams Conference calls - e.g. those created during Consultation via Attendant - do not support transfers, which also prevents Context Parameters from being handed over.
→ If you require Context to be transferred, use Blind Transfer or Safe Transfer scenarios respectively.
Transfers and RONA State
INC Transfers and RONA State
✅ Note: Only applies if “Persistent RONA” is enabled via Distribution Service Settings.
-
When the target User is already is in RONA state.
⮑ A message will be shown after a transfer attempt is made: “Transfer cannot be started to a User, who is in a Nimbus Task”. There will be no User Session for Nimbus Reporting.2 -
When the target User ignores / doesn't answer the transfer (e.g. Timeout), Nimbus will not flag users with RONA state1.
⮑ User Session in Nimbus Reporting marked “Cancelled”2 - When the target User actively declines a transfer will also not flag users with RONA state.
⮑ User Session in Nimbus Reporting marked as “Declined”.2
1🤔 Why is RONA not applied in this the case? There is no persistent RONA state if User has not been selected by the Nimbus Task Queue and Distribution.
2 Depending on the Attendant Console transfer scenario (safe/blind), the call will return to the initial User or be lost. This is not related to RONA behavior.
Transfer to Teams Auto Attendant and Call Queues
INC Transfer to Teams Auto Attendant and Call Queues Limitation
☝Transfers towards the UPNs of Teams-native Auto Attendants’ or Call Queues’ Resource Accounts will fail. Based on the PSTN connectivity option used, transfers towards the Resource Accounts' assigned phone numbers will work as summarized in the table below.
| Transfer Type | Direct Routing | Calling Plan | Operator Connect |
|---|---|---|---|
| Attendant - Safe Transfer | 🛠 | ❌ | ❌ |
| Attendant - Blind Transfer | ✅ | ✅ | ✅ |
| Attendant - Consultation Call | 🛠 | ❌ | ❌ |
Workflow Conversation Handling Activities > Transfer > “Leave Nimbus” disabled |
🛠 | ❌ | ❌ |
Workflow Conversation Handling Activities > Transfer > “Leave Nimbus” enabled |
✅ | ✅ | ✅ |
🤔 Why are transfers failing? Is there a workaround?
🔎Analysis: This is caused by Microsoft Teams limitations on what voice applications (such as Call Queues, Auto Attendants, and Nimbus) are allowed to do. This cannot be circumvented by Nimbus.
🛠 Workaround: For these transfer types to work, Reverse Number Lookup (RNL) has to be disabled in the Resource Account's Phone Number Assignment. RNL can be disabled by executing the following Teams PowerShell command:
Set-CsPhoneNumberAssignment -PhoneNumber <phone number assigned to the CQ/AA resource account> -ReverseNumberLookup SkipInternalVoip⮑ After disabling RNL for a Phone Number Assignment, Teams will automatically forward the call to the Direct Routing SBC, which then needs to redirect it toward the Resource Account of the Call Queue or Auto Attendant.
Transfer to PSTN Licensing and Limitations
INC Transfer to PSTN Limitation
☝Out of the box, Nimbus and related addons can only perform PSTN transfers according to Microsoft's licensing and constraints.
INC PSTN License Check Enforcement Notice
☝Ahead Notice: Microsoft enforcing PSTN license checks for bot calls
From: https://devblogs.microsoft.com/microsoft365dev/enforcement-of-license-checks-for-pstn-bot-calls/
Microsoft has announced changes to PSTN license checks for bots. From the Blog Post of Microsoft:
As part of Microsoft’s feature parity with Teams Phone extensibility, we’re announcing the enforcement of Phone System license checks for Bot-initiated transfers to Teams users. This current gap in our systems will be addressed in June 2025.
Microsoft Teams requires that Teams users behind applications such as queue applications require a phone system license and the user to be Enterprise Voice Enabled. We’re aligning the Microsoft Graph API with that requirement.
What is the change?
Effective June 2025: Teams users will still have the option to transfer calls to other Teams users manually even if they don’t have a PSTN phone system license. Bot-initiated transfers and add participant requests to non-phone system enabled users will be blocked.
🤔How does this affect Nimbus? Nimbus uses bots to initiate and monitor (safe) transfers and create call conferences.
✅Analysis / Required Action for Tenant Administrators / Service Owners:
This change mandates the use of a PSTN License on all Users you either transfer to or start a consultation call with. If Microsoft decides to pull through with this change by June 2025, all Nimbus transfers and consultation calls will be blocked and fail without any possible workaround or error handling.
🤔Which PSTN license do I need to acquire?
As of 2023, "Microsoft Teams Phone Standard" licenses are no longer supported by Microsoft. Previously, those licenses were viable for Nimbus. Regardless if you are using Direct Routing, Calling Plans, Operator Connect, the "Microsoft Teams Phone Resource Account" license is now always required.
| Your Setup | Required License |
|---|---|
| Direct Routing |
"Microsoft Teams Phone Resource Account" |
| Calling Plan |
"Microsoft Teams Phone Resource Account" + "Microsoft Teams Domestic Calling Plan" or "Microsoft Teams Domestic and International Calling Plan" or "Microsoft Teams Calling Plan pay-as-you-go" + "Communication Credits" (if these aren't already included as part of your plan) |
|
Operator Connect |
"Microsoft Teams Phone Resource Account" |
☝Please note that Luware staff cannot give recommendations on which license plan is best suited for your needs. Depending on your scenario, additional Teams App licenses may be required. Exact details are to be discussed with your Microsoft contacts.
🔎Also see: https://learn.microsoft.com/en-us/microsoftteams/teams-add-on-licensing/virtual-user
🤔How does PSTN licensing affect Service and call transfers?
Assuming that the initially called Service has (no) PSTN license assigned - the following scenarios may unfold:
Scenario A - Service A has a PSTN license. Transfers to other Services occur.
⮑ The PSTN license carries over throughout transfers to other Nimbus Services B and C.
⮑ As the license carries over, a PSTN transfer to an external target is possible from either Service.
Scenario B - Service B has no PSTN license. A Transfer to Service C occurs which has a PSTN license.
⮑ The customer skips over Service A and manages to reach Service B instead.
⮑ The PSTN license is missing on Service B, so nothing is carried over to Service C.
⮑ Even if Service C has its own PSTN license, a PSTN transfer to an external target is not possible.
🌟Learnings:
- Nimbus will use the PSTN license – and create a (transfer) Session – from the FIRST Service responding to a call.
- Regardless of how many internal Service transfers are performed thereafter, the FIRST Service PSTN license remains in effect.
- If a PSTN license is missing, the transfer task will fail and be treated accordingly by the System.1
- Even if a Service being transferred towards has a PSTN license, it cannot be added in post, as the Call Session is already ongoing from the first-responding Service.
✅ For your licensing needs this means: If you require PSTN transfer functionality, you'll need to ensure that this Service is handling all your incoming calls.
- For ONE first-level / Front Desk Service, you'll need a PSTN license for this particular Service.
- For MULTIPLE first-level Services scenario, you'll need PSTN licenses for all first-level Services.
1🔎 Assumption: Workflow takes the normal “Exit” Announcement route and Service Session will conclude with a “Transfer failed” outcome. For more details on analyzing your Reporting results, refer to Nimbus Reporting and Static Dimensions > "Service Session Outcomes"
☝Note that handling and tracking of running cost for PSTN licenses is outside of the Luware support scope. If you however require assistance in extending and/or configuring your Nimbus Services for PSTN, our support will gladly assist you:
Luware Support Address
| Luware Website | https://luware.com/support/ |
|---|---|
| Luware Helpdesk | https://helpdesk.luware.cloud |
| Cloud Service Status | https://status.luware.cloud/ |
Transfers and Nimbus Reporting 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 blind / 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 |
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.
Transfers to disabled Voicemail
INC Voicemail Limitations
☝KNOWN LIMITATION: Currently, there is no way to check ahead if a (target) user has voicemail features enabled. This is a design limitation by Microsoft which Nimbus currently cannot circumvent.
Additionally, the voicemail feature may also be deactivated as part of a tenant-wide IT policy by your administrator. There are also known cases where Microsoft accepts transfers to voicemail but the recipient has no means to check (e.g. MS Teams Client / License restrictions). We highly recommend using this feature only in case voicemail is enabled for the Microsoft Teams user.