Conversation Context

Enterprise Routing Contact Center This Feature requires an Enterprise Routing or Contact Center license, allowing you to apply context via your  Extensions Service Settings.

Preconditions: Conversation Context must be defined via Configuration beforehand and made available on the service's respective Organization Unit (or higher) before they appear in related service settings. 

Considerations: Before using context in Nimbus, please take the following considerations into account:

Is Nimbus open in the browser or Assistant installed?

✅ During an incoming task Nimbus Portal must be open in your browser, so context tabs can be opened

Nimbus Portal Links:

INC Nimbus Portal URLs

Switzerland 01 https://portal.ch-01.luware.cloud/
Switzerland 02 https://portal.ch-02.luware.cloud/
Germany 01 https://portal.dewe-01.luware.cloud/
Germany 02 https://portal.dewe-02.luware.cloud/
United Kingdom 01 https://portal.ukso-01.luware.cloud/
Australia 01 https://portal.aue-01.luware.cloud/
West Europe 01 https://portal.euwe-01.luware.cloud/
East United States 01 https://portal.use-01.luware.cloud/
Nimbus Portal URLs

Make sure to configure your web proxies to allow access to these domains or whitelist the complete *.luware.cloud domain.

💡Notes:

  •  The Nimbus Teams Tab within MS Teams cannot open context by itself as it is prevented by MS Teams. 
    → Within the Nimbus Personal App you can use the "Go to Website" Icon located at the top right, to the same effect of using the URLs above.
  • The Assistant App - when installed on your local PC - can open your browser and related context automatically via the use of Service Call Templates.
 
 

✅ Are pop-ups allowed by Nimbus in your browser?

✅ Context may get blocked by your browser, so Nimbus must be allowed.  
→ Make sure that Microsoft Teams and Nimbus URLs are except from any pop-up blockers.

Browser popup warning

💡Notes:

  • Some browsers block pop-ups as a default. You may need to do a test call to see and allow the blocked pop-ups.
  • Your company IT policies, firewalls or additional Adblocking extensions can also prevent opening of context. If the problem persists, talk to your system administrator.
 
 

✅ Do all users have rights to “see” the context?

Once defined, Conversation Context items may be reused and opened in multiple services simultaneously. Depending on your use case there are some points to consider:

  • URL access: Context configured via Service Settings is opened for all users of that service. Ensure that your users all have access to any outside URLs you provide as context.
  • Item visibility: Context items can be made available Tenant-wide (e.g. when highly visible in Organization Units). When doing so, consider clear context naming conventions to ensure that you and fellow service administrators apply the right context items in their Service Settings.
  • Dynamic flexibility: By using our Microsoft Power Automate Connector you can greatly extend the possibilities of showing dynamic context URLs to your users. Refer to our steadily growing list of Power Automate Use Cases for inspiration on how to leverage external systems for rich Nimbus context.
 
 
 

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.

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 Parameters1 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
  • Lookup reference for providing context on an incoming caller (e.g. identified by Mail Address, Name, UPN, PSTN number)
  • Extend the search capabilities for Nimbus UI

GDPR 1 (Context) Data Lifetime: The Nimbus OData Feed and related Reporting Database do NOT automatically include or store Custom Context within the Nimbus Reporting Model. This is also due to data privacy concerns, as any user with widespread Nimbus Reporting privileges may potentially access sensitive Customer data stored during a call (e.g. medical conditions, credit card numbers, social security details) .

While certain Nimbus UI elements like the Sessions List CAN show a history of Call Data and Context Parameters after a Session concluded, the actual Context and Parameter Data retention time is limited, as defined in the Whitepapers in our Documents section.

⮑ Any sensitive Custom Context data must therefore be safely stored in external systems using the Nimbus Power Automate Connector.

 
 
 

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

 
 
 
 
 

Displaying Conversation Context in Nimbus

By opening or calling pre-defined URLs automatically, Conversation Context items in Nimbus can help the user perform mid-session or After Call Work (ACW) tasks quicker and serve the customer more efficiently.

Possible use cases for Conversation Context could be:

  • Create, update or open incident tickets in your based on incoming call information.
  • Provide directly embedded customer feedback or Instructions for your agents, based on the called services.
  • Extend the call scenario with further browser-based applications such as CRM, SAP or custom-developed apps.

Conversation Context items can either be shown:

  • Nimbus In-App (e.g. Embedded Context Widget within My Sessions).
  • As external Website: Opened when either Nimbus is running In-Browser.
    💡Optional: Via installed Assistant App running in the background, context can be opened with conditions, even while the browser is currently closed.

Creating Conversation Context

To create a new Conversation Context entry for later use, perform the following steps: 

  1. Click on " Add ".
    ⮑ A dialog to add context opens.
  2. Specify a Name  for the context entry.
    💡 This is just for identification purposes in lists and menus.
  3. Specify the Organization Units to define where this context should be available (e.g. only a particular team / division or tenant-wide). 
    🔍 This also determines the entries of "Custom Parameters" you can pick from during step 4.Add Context Entry
  4. Enter a base URL to open (e.g. your HelpDesk, CRM or other system). 
    💡 You can also use a custom context parameter to form your (entire) URL. A validation will check for protocols such as "http://" or " $(CustomContextParameters" contents and warn you when the URL is seemingly invalid.
    1. Click “ Custom Parameter” to enter the parameter placeholder at your cursor in the URL field.
    2. Add any existing "+ System Parameter" in the same way.
  5. Click " Create " when done.

Timing Matters

An incoming call Workflow is tied to at Trigger Events which can use Flow Actions to update System and Custom Parameters. The Context items open immediately when a call is distributed to the Nimbus user. Make sure to adapt your workflow accordingly so that any retrieved information can be gathered timely to serve as part of your context URL.

 

Applying Conversation Context

Context can be applied in various ways. Use the tabs below to learn more:

My Sessions (embedded)

Context can be shown in the My Sessions “Embedded Context” widget, as configured via Extension Service Settings.2

Defining embedded Context in Service Settings

Your context will then automatically open as you accept an incoming Nimbus task:

Example website shown as embedded context in the widget

💡 Use this method to avoid opening of extra tabs, allowing users to focus on the Nimbus Personal App & My Sessions view at all times.

INC Website Embed Limitations

WEBSITE EMBEDDING LIMITATIONS

Some websites prevent IFrame embeds on remote sites, which cannot be circumvented. When you try to embed such protected URLs, errors like 401 (unauthorized) or a "Refused to Connect" message will be shown instead of your desired output.

✅ Possible Workarounds:

  • If available, consult your external source website support to check if any iframe-referrals are allowed. Some services offer specialized data widgets for that purpose or provide authorized token-URLs that you can use.
  • If you have access to whitelists on your source website, try to allow the *.luware.cloud domain for external embedding / referencing.

Show more technical information...

 There are two types of HTTP headers in websites that control iframe loading:

X-Frame-Options: DENY

Content-Security-Policy: frame-ancestors 'none'

The HTTP Content-Security-Policy specifies valid parents that may embed a page using <frame>, <iframe>, <object>, or <embed>.

A website header called x-frame-options specifies the access prevention, determined via the following values: 

  • if set to DENY the site isn't allowed to be loaded in iframe 
  • if set to SAMEORIGIN the page can only be embedded in a frame on a page with the same origin as itself.
  • if set to ALLOW-FROM the page can only be displayed in a frame on the specified origin. This only works in browsers that support this header.

🔍 Related Sources:

 
 
 
 
 

Assistant App

Assistant works standalone App and can provide Context selectively to individual users. As Administrator you can configure the following:

  • (Service or User) Call Templates that specifically trigger data requests and can open other local apps or scripts on an incoming call. These Templates offer a more fine-tuned experience is configured per user / service, performing automated tasks in the background such as running extra apps or web requests.
  • Open Conversation Context as the call is still ringing or has been accepted.

💡 Once Assistant is installed and running in the background of a user's PC, a permanently opened Nimbus browser tab (e.g. My Sessions view) is not required anymore to get call context.

Conversation Context and Service Templates applied in Service Settings

Within a Service you can configure Assistant as follows:

Audience What to use How to Configure

Single Users (Agents)

(With Assistant License)

Direct Templates are assigned and triggered by Assistant for an individual user, opened in their system-default browser during an incoming direct call. Assistant Configuration. Once created, User Templates can be added via Assistant User Settings.

All Service Users

(Enterprise and Contact Center Licensed Services)

 

Service Templates are assigned and triggered by Assistant during an incoming service call. Assistant Configuration. Once created, Service Templates can be added via Extension Service Settings.1 
Conversation Context can be opened in the default browser for all Service Users during an incoming service call. Configuration. Once created, Context Items can be added to the via Extension Service Settings.2
 
 

1 Read more about Assistant to learn how context actions can be triggered during an incoming or ringing call. The related Use Case - Chaining of Assistant requests explains how to create such Call Templates step by step.
💡This method can also be applied to Direct Templates assigned to a user, as both concepts are very similar.

2 Refer to Use Case - Defining and using Conversation Context provides a step-by-step example on how to configure this. This method is the same as opening Context via My Sessions.

 

 

Table of Contents