Luware Knowledge

Nimbus Portal Nimbus Admin Nimbus Release Notes Luware Cloud Status
Home Nimbus Usage of Nimbus Task Handling

Context Handover

How Context is Created, Stored and Transferred during Nimbus Sessions

💡In Nimbus, 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.

 

What is “Context” in Nimbus?

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).

Nimbus

Power Automate
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.

Nimbus

Power Automate
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.
 
 

Viewpoints on Context 

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: 

  • WHEN did WHICH CUSTOMER call WHICH SERVICE?
  • WHERE was the call TRANSFERED to?
  • WHICH Nimbus USERS took the call?
  • WHAT was the RESULT of 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).

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 TOPIC did the customer call WHICH INITIAL SERVICE about?
  • HOW LONG has the call been ongoing, and how many PRIOR TRANSFERS?
  • WHO ELSE has spoken to the customer before?
  • WHAT FURTHER INFORMATION was provided in prior calls?
  • HOW CAN WE HELP in 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:

  • Call Metrics, such as time spent in Sessions, Waiting times, Transfers.
  • Session History: Previous interactions the customer has had with one or multiple related services and users.
  • Customer identifier: To quickly check and potentially fast-track the customer to the right service and its workflows.
  • Last connected user / Preferred Users (e.g. to avoid having to pick up previous calls from scratch, blocking both user and customer longer than necessary)
  • Collected Data, e.g. Tags and Codes for a comprehensive Power BI Report.
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:

  • (First) Service called (e.g. an Emergency Line or regular Service).
  • Amount of (previous) User Sessions.
  • Overall session time (across multiple users, or when transferring to a different service).
  • Privacy settings: Any collected Custom Context must be either handed over or scrubbed in between transfers.
  • Task Priority, which can be different per service, maybe influenced by the aforementioned context.
User Correctness: Getting the appropriate information into the hands of the right user.

Context to allow Agents to work efficiently:

  • Need-to-know: Determine which information is relevant to this user in particular (depending on call situation, background, etc.)
  • Timeliness: Each user needs to be informed with the correct and latest information.
  • (Previous) Users called - e.g. for efficient internal follow-ups.
  • Overall Call duration, to keep an eye on KPIs and user satisfaction.
  • Issue at hand: Customer reasons for calling, including context and notes already provided by other Agents.
  • Conclusions: Observations made during the conversation, technical or product-specific codes, decisions, follow-ups, tickets, etc.

🔎Configuring Nimbus Context in the UI

Nimbus may show Context in different UI areas, popups and widgets, but primarily focuses on My Sessions, Assistant and Attendant Console  where Interactions with Customers occur. This configuration is explained under Conversation Context. 

💡It is noteworthy that the Context shown in the UI is “Viewpoint-agnostic”, so it can consist of System Data mixed with Customer Details and (manually enriched) Custom Context, but the Nimbus User will not necessarily see where this information is originally coming from.

 
 
 
 
 

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 Custom Parameters can be transferred alongside. Individual service settings determine:

  • If the Conversation Context is stored for a certain retention time and 

  • 
 if Custom Context Parameters should be retained during a transfer to Services or Users.
Conversation Context: storage and transfer settings.

🔎 Custom Context Parameter Transfer Settings 

The following Diagram is meant to illustrate the effects of context-related service settings.

  • Each service can individually steer settings. 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.
  • Call & System data will always transfer to Services and User. 
    • Custom Context Parameters will be available on the receiving service.
    • Custom Parameters will be transferred to users only if configured on the originating service. If toggled off, they will be nulled/reset.
  • 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.
Diagram: Context-Related Service Settings and how related data gets transferred and updated using Power Automate
 

 

✅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: 
  • 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:

Transfer 
to User 
to Service

By User on 

✅ Call Data + Customer.Custom Fields 
and 
System Data.

⬜/✅ Custom Context Parameters only if enabled in respective Service Settings.

✅All Call Data + Custom Fields, 

System Data and 
Custom Context Parameter 

get transferred.
By Service
 ❌ No Context gets transferred.1

✅All Call Data + Custom Fields, 

System Data and 
Custom Context Parameter 

get transferred.

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: MS Teams Conference calls - created during Attendant Consultation - do not support transfers, which also prevents Context Parameters from being handed over. 
    → If you require Context to be transferred, use Blind or Safe Transfer scenarios respectively.
  • 3 No Multi-Transfer: Currently you can only transfer Sessions (and related Context) once. Afterwards, the “Transfer” button will be disabled. 
 
 
 

Transfers and RONA State

INC Transfers and RONA State

✅ Only applies if RONA is enabled via Distribution Service Settings.

  • When the target User is already is in RONA state.
    ⼑ A message will be shown: “Transfer cannot be started to a User, who is in a Nimbus Task”. There will be no User Session.
  • When the target User ignores / doesn't answer the transfer (e.g. Timeout), Nimbus will not flag users with RONA state, as the Nimbus User was not initially selected by the Nimbus Task Queue and Distribution system.
    ⼑ User Session in Nimbus Reporting marked “Cancelled”
  • When the target User actively declines a transfer will also not flag users with RONA state. 
    ⼑ User Session in Nimbus Reporting marked as “Declined”.

đŸ€” Why is RONA not applied in this the case? In a normal scenario, Nimbus selects Users via Task Queue and Distribution system, flagging them accordingly. Manual targeting will not cause RONA, as it could prevent Users 

⼑ Regardless of either Ignore / Decline scenario:  Depending on the transfer type (safe/blind), the call will return to the initial Nimbus / Attendant User or be lost.

 
 

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.

đŸ€”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 Service A has a PSTN license assigned - but further Services don't - the following scenario may unfold:

Scenario A - Service A workflow is configured to transfer the caller to Service B. The license of Service A is used, the PSTN transfer occurs. The PSTN license is re-used throughout further transfers to Services C...D
x
and so on.

Scenario B - Service B is called directly instead. Now the workflow of Service B attempts a redirect to either service A or transfer to C. The PSTN transfer fails due to a missing license on Service B.

🌟Learnings:

  • For one first-level-response service: If you handle first-response calls always via the same service, you need a PSTN license for that particular first-level service.
  • For multiple first-level-response services: If you handle first-response calls always via multiple services, you need a PSTN license for all those first-level services .
  • Nimbus will attempt to use the PSTN license of the first service that responded to a call, regardless of how many further internal service transfers are performed thereafter.
  • If no PSTN license is found on a service that requires it for a transfer, the transfer task will be considered as failed and treated accordingly by the system (e.g. workflow exit announcement, reporting "transfer failed" outcome).
 
 

☝Note that handling and tracking of running cost for PSTN licenses is outside of the Luware support scope. If you 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/
Luware support contact details

 

 
 

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 transfers to Internal Destination B, which accepts Transferred Internally Accepted User Internal Transfer Success
User A transfers to Internal Destination B, which does not respond (ignore) Transferred Internally Cancelled

On safe transfer: → Last User A outcome 

On blind transfer: User Internal Transfer Failed
User A transfers to Internal Destination B, which rejects Transferred Internally Declined Declined
User A transfers to Destination B Voicemail 2,3,4 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 Automatic Voicemail prevention: 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. 

4 Disabled Voicemail: Refer to the “Transfer to disabled Voicemail” limitation below.

 

 

 

 

 

 

 

 

 

 
 

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. 

Voicemail Redirect Setting in MS Teams

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.

 
 
Attendant - Blind Transfer

New Design for Attendant Console This page describes both Attendant Console 1.0 a...

Attendant - Service Transfer

New Design for Attendant Console This page describes both Attendant Console 1.0 a...

Conversation Context

Enterprise Routing Contact Center This Feature requires an Enterprise Routing or ...

Extensions Service Settings

In Extensions Service Settings, you can manage extension Nimbus Features such as ...

Table of Contents