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 Parameters	Custom Parameters (Defined in Nimbus UI and Workflows) Custom Context Parameters (Defined during Flow Actions)	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.

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: 

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

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