In Extensions Service Settings, you can manage extension Nimbus Features such as Codes and Conversation Context displayed on the My Sessions overview. Enabled features are immediately available to all Nimbus service team members.
Licensing Preconditions
Enterprise Routing Contact Center The Extensions tab is available for Enterprise and Contact Center licensed services. Please note that some extensions described below will only be visible for configuration when you have the according license applied via the Service Administration. Refer to Nimbus Features for an overview and get in contact with Nimbus customer success if you require a demonstration.
💡 For Enterprise services, you need to have a Teams team defined in order to see the Extensions tab.
Codes
Enterprise Routing Contact Center This Feature requires either an Enterprise Routing or Contact Center license on the service. Codes are selectable entries can be defined by service owners to appear in My Sessions or Assistant to help users specify the contents or task conclusion during and after a call (After Call Work).
Good to know
- Codes selected by users after completing task will be stored as part of historic reporting and made visible via BI Template.
- Unlike Tags a code must be predefined via this list to appear for users of the service. This also means that users of multiple services will see different codes for selection, depending on the service that was handling the task.
- The usage of codes as either “Secondary” or “Primary” is purely cosmetic, without system-relevant differences.
✅ Preconditions: Primary and Secondary Codes must be defined via Configuration beforehand and made available on the service's respective Organization Unit (or higher) before they appear in this list.
Learn more…
Once Codes are configured, click “Add” to add any available code to either the Primary or Secondary list. You can also sort the entries via drag-and-drop to change their order of appearance for users.
Assistant
Assistant works standalone app and can also provide context during calls to individual users. As Administrator you can configure the following:
- Define (Service or User) specific Call Templates that trigger data requests and can open other local apps or scripts on an incoming call.
- Reuse or define specific conversation context opened as the call is ringing or accepted.
💡 Learning: 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. The browser will open and show context automatically on incoming tasks.
Within a Service you can configure context for Assistant individually as follows:
| Target | What can be applied | How to Configure |
|---|---|---|
| Users (Agents) | Direct Call Templates are assigned and triggered by Assistant for an individual user, opened in their system-default browser during an incoming direct call. |
✅ Direct Call Templates containing the trigger points and actions and must be defined via Administrator-side Configuration first. Once created, Templates can be added to a user via Assistant User Settings . 🔍 Our Use Case - Chaining of Assistant requests provides a step-by-step example. |
| Services | Service Call Templates are assigned and triggered by Assistant during an incoming service call. |
✅ Service Call Templates containing the trigger points and actions must be defined via Administrator-side Configuration first. Once created, Templates can be added to a user via Extension Service Settings. 🔍 Our Use Case - Chaining of Assistant requests provides a step-by-step example. |
| Conversation Context is opened by Assistant in the Nimbus users default browser during an incoming service call. |
✅ Conversation Context items containing the URLs to open must be defined in the Administrator-side Configuration first. Once created, they can be added to a user via Extension Service Settings. 🔍 Our Use Case - Defining and using Conversation Context provides a step-by-step example on how to configure this. |
My Sessions
This section controls Widgets, Parameters and other information shown in My Sessions.
Conversation Context
Preconditions
✅ Enterprise Routing Contact Center This Feature requires an Enterprise Routing or Contact Center license.
- Conversation Context items must be defined via Configuration beforehand and made available on the service's respective Organization Unit (or higher) before they appear in this list.
- Context can consist of static URLs, but also use dynamic Custom Parameters or System Fields and Parameters. If you want to learn more, visit
🔎 The following detail settings below all impact Context and related configuration items. We recommend visiting linked pages to get a picture of the possibilities. We also offer a Context Handover concept page for more detailed considerations on displaying context.
Store Conversation Context Data
INC Store Context Data
GDPR After a service task has concluded, any historic session and customer context data – e.g. as shown in the My Sessions widgets – will by default not be stored by Nimbus.
While disabled:
⮑ the "Session Details" of any historic task records will show “Not Available” instead within My Sessions and Historical Sessions.
⮑ Previous custom Parameters / and Conversation Context items (e.g. Customer details or URLs dynamically retrieved and formed via Nimbus Power Automate Connector) will not resolve or open correctly anymore.
This storage behavior can be changed by enabling the “Store Conversation Context Data” in Extensions Service Settings:
☝ Note that the “Store Conversation Context Data” option is disabled by default as potentially sensitive caller data can appear in historical records and seen by Administrators (e.g. via Sessions List). Therefore…
- … read the consideration below to understand its effects.
- … note that this setting has no retroactive effect, so only the data collected after enabling the feature will get stored for the retention period.
- … note that the setting must be enabled individually per service (OPT-IN).
🤔What happens when I enable this?
☝Task information / Session detail data is stored per service session on call termination (either transfer by workflow or user).
- Within the UI of My Sessions and Historical Sessions
- Custom (user created) Parameters
- System Fields and Parameters (both “Custom” and "System" parameters like Call ID, Service UPN, etc.)
☝ Restrictions on concluded sessions (e.g. within My Sessions) apply as follows:
- ... the "Embedded Context widget" will resolve with the currently configured URL with a previously saved call information. This means that also historic sessions will use the link currently configured in the Extensions Service Settings .
- ... the separate "Open Context" link remains clickable if at least one Conversation Context URL is currently configured.
- ... the "Session Details" widget will still show Custom and Customer parameters if available.
☝ Not stored (regardless of setting) are:
- Default "My Session Parameters" user data is not stored as it is always retrieved dynamically from the internal user directly of your Tenant.
🤔What happens in service transfer scenarios?
Nimbus always stores live context on transfer to services (either initiated by workflow or user). The "Store Conversation Context Data" option will have no impact there.
☝ However, enabling the "Store Conversation Context Data" setting will cause such live context data to be stored as historical record after call termination. This also applies on each transfer between services, creating a historical record entry for each service that has the setting enabled.
In an example transfer scenario this may cause historical data to “accumulate” between services, as data gets updated and appended.
Example - Transfer from Service A to B to C:
| Parameter | Service A ► transfer to | Service B ► transfer to | Service C |
|---|---|---|---|
| Customer Name | John Doe | John Doe | John Doe |
| Spoken Language | German | <Not Relevant> | <Not Relevant> |
| Gender | <Not Relevant> | Male | <Not Relevant> |
| Ticket ID | #1111 | #3151 (overwritten Ticket Parameter) | <Not Relevant> |
| “Store Conversation Context Data” enabled | ✅ | ⬜ | ✅ |
| Stored Historical Sessions data shown | John Doe (1) German Not used #1111 |
John Doe (1) Not available (not stored) Not available (not stored) |
John Doe (1) German (from Service A) Male (from Service B) #3151 (from Service B) |
(1) The user name will always be resolved from a UPN / PSTN when it was found within the existing O365 user directory.
🤔How long is data being stored?
Caller info is updated on a “terminated” workflow Trigger Events and stored for a maximum of 30 days for the last available service session (in case of transfers). Conversation Context data will also be stored for failed, aborted or “killed” calls.
☝ Note: After 30 days the data is cleared. This also happens when either the Service or Tenant is being unprovisioned (removed from Nimbus Clusters) while Uninstalling Nimbus.
🔍 Whitepapers: You can also learn more about the data retention policy in our whitepapers, available in the Documents section.
⮑ Customer-Side Backup responsibility: If you wish to store mission-critical or personal session data permanently, you need to do so during an active session and within a system of your choice (e.g. a CRM or Database).
Keep Custom Context Parameters on transfer
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.
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 (note that restrictions apply3)
- Attendant - Blind Transfer → To User or Service (note that restrictions apply3)
- 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: 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.
Widgets
✅ Individual Preconditions: Note that Features below are separately licensed and may not show in your UI if preconditions are not met.
Widgets extend the My Sessions UI with additional functionality. The following widget settings can be configured:
| Setting | Description |
|---|---|
| Codes and Tags | ✅ Preconditions:
💡 Tags can be freely defined by users during incoming calls. Suggestions will be auto-completed based on previously provided tags.
 |
| Embedded Context | ✅ Preconditions:
💡 Please note that only one Context item can be shown embedded per service call. 🔍 Functionality is the same as described in → chapter Conversation Context above. However, embedding limitations apply (see below).  INC Website Embed LimitationsWEBSITE EMBEDDING LIMITATIONSSome 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:
Show more technical information...There are two types of HTTP headers in websites that control iframe loading:
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:
🔍 Related Sources: |
| Live Caption |
✅ Preconditions:
 Tip: Hiding captioning in the backgroundNote that Live Caption can only be used with both Live Caption and Transcription enabled in tab Virtual Assistant. However, if you want to hide Transcription from the portal (e.g. if you want to process it only in the background), disabling Live Caption in tab Extensions will prevent transcripts being shown in the widget. |
| Transcription |
✅ Preconditions:
Transcription processing in ACW💡If you have ACW configured in Distribution Service Settings and need it for session closure, you may need to wait for an ongoing saving process of your session's transcription to finish. Once the final transcript is available, it appears in the Transcription widget and you can use it for your ACW.  |
| Session Details | ✅ Preconditions: This feature can be used for any service. 
✅ Extended License Features: The amount of available parameters is greatly extended with higher Nimbus Feature license tiers. Note that a service License downgrade is being prevented when you still have custom or system parameters in use. Before attempting to downgrade your service license, remove additional parameters first and return the view to "My Session" defaults. Advanced Routing✅ Advanced Routing My Session Parameters:
 💡Good to Know: If you remove any of the existing entries, they will re-appear in the "My Session Parameters" list and can be re-added. Enterprise Routing / Contact CenterEnterprise Routing Contact Center Additional System Fields and Custom Parameters for your "Session Details" become available with an Enterprise Routing or Contact Center license on your service:
 🔎Notes on Parameters in Session DetailsAny custom/writable Custom Parameter data is retrieved using the Microsoft Power Automate Connector.
|
| Map | ✅Preconditions: Map locations are only shown when previously retrieved from an external directory, e.g. by using the Microsoft Power Automate Connector to look up caller data.
⮑ When successfully retrieved, an available a google-maps location will be shown based on either the address or IP information of the caller. Depending on the available info this map will provide more specific or general details. |