Service Settings

An overview of all Service Settings Tabs




  • Service settings are available to service (team) owners TEAM OWNER. You can access them via Nimbus's Frontend menu or in the team headers.
  • Tenant administrators TENANT ADMIN have extended access to service settings via the Administration backend.
  • Regular users TEAM MEMBERS (Agents) will not see the settings option at all. 


  • Settings rely on shared data entities managed via the central Nimbus Configuration. We highly recommend to check there first before adjusting your settings to avoid having go back-and-forth.
  • Settings- and options visibility is determined by Organization Units (OU) and Role Access Concept. Access to certain features may be hidden from view or locked, despite having an admin role.
  • To reduce complexity, settings may be hidden as licensing or Nimbus Features must be enabled first.

Settings Tabs

🔍 The tabs contents below reflect the service settings available in the Nimbus UI. Please note that some tabs are restricted to certain Service types and show when related Nimbus Features are enabled.


General Service Settings

Contains general service settings such as the Service name, PSTN number, Opening Hours and Reporting settings.

The "General" tab provides options that relate to Nimbus provisioning. Here you can also initiate "Test Calls" via MS Teams, which is particularly useful when you want to test changes to your Workflows. As a Service / Team Owner you can see the following details.

🔍Note: Entries marked with ☝ require a (re)execution of a Provisioning Script. → See Note below on "Triggering Changes / Admin Consent"

Name  - Name of the Team as it is defined in Microsoft Teams client. Nimbus 
Service Display Name

Outwards facing Clear Name of the Service as Callers / Customers will see it in their Client.

💡 By default equal to the "Team" Name as it is shown in Microsoft Teams. Can be overridden if needed.

Service UPN The UPN (User Principal Name) under which the Service can be reached via user directory.
Application ID - The Application ID is provided during initial setup and cannot be changed. Used only for reference, e.g. during support cases or when adjusting Required App Permissions
Test Calls -

A test call will directly call the Nimbus call-bot and establish a connection to your service. You can use this feature to test your workflows and/or distribution settings.

💡 Please note that this feature will not test any PSTN numbers assigned to your service. To test a PSTN you need to call via cell phone or landline.


  • Nimbus bot operation is not affected by service name changes. Calls will continue to be distributed.
  • A service name change will also not impact the (search-discoverable) service UPN name specified.
  • Nimbus users will see team name changes reflected in their "My Teams" listing immediately.

💡 As team owner you can change your team name directly within Microsoft Teams (native, non-Nimbus functionality):

  1. Within MS Teams, locate your team 
  2. Click on the "..." icon or right click the team name
  3. Select "Edit Team" → A dialog will open
  4. Change the team name (and optionally the description) to any desired content. → The Nimbus "settings" tab will reflect the new team name upon next load. 

UPN and Service Display name changes are tied to Tenant Admin Consent and provisioning script rerun which can take several minutes to take effect. Any change is therefore marked with a ☝ Warning in the UI.

🔍 I'm a Service Owner - why are certain Service settings still locked against change? 

  • The full amount of settings is accessible only to Tenant / Partner administrators. Certain features are part of the Nimbus installation procedure and cannot be changed past deployment without provisioning a new service again.
  • Certain changes are bound to the Service type or License applied. A downgrade may be prevented until you disable certain Nimbus Features or delete involved data entities.

🤔 I'm having technical questions before changing my service settings. Where can I find help?



Allows to assign a public telephone number (Public Switched Telephone Network) to your service. 

☝ This setting should not be enabled without subject-matter knowledge or prior Tenant Admin / Nimbus support contact consultation.

🤔 Refer to the Installation Prerequisites for further info on PSTN / Number requirements.

🤔 Why is this necessary? Administration and licensing of PSTN numbers is outside of Luware control. Erroneous Number and License assignment may result in additional set-up efforts and running costs. Get in touch with your Nimbus support representative if you need help with this setting anytime after your initial Nimbus deployment. Our FAQ and Troubleshooting section is also updated frequently.


Opening Hours

Allows you to apply Opening Hours for your service team. Handling and routing based on opening hours is part of your Workflows e.g. by routing the call according to the "Check Opening Hours" Workflow Activity.

✅To be selectable in this Opening Hours entry (data entity) must be created first - and made available within the same Organization Units of the service or Tenant-wide.

Define primary and secondary opening hours

Each team may decide if the opening hours are defined as primary or secondary. This is determined via service-individual Service Settings > "General" Tab.


Opening Hours Period Ruleset:

  1. If at least one defined period is found in the primary opening hours calendar, this period is prioritized.
  2. If there is no period in defined primary calendar, the secondary calendar period is applied.
  3. If no appointment is found in either calendar (with a secondary configured), the "Default" state of the first calendar is used.
  4. The default of the secondary calendar never applies in a two-calendar scenario. If the secondary calendar has no periods defined it is effectively ignored.

🔍 Rule of thumb: Primary Defined? > Secondary Defined? > Both no? > Use Primary Default!

💡 An example of how this rule is applied can be found below.

Service Settings with applied opening hours. The current applicable status is shown under "Active Opening Hours".


Show me an example

In this example there are two calendars defined: one provided the Admin (e.g. Company-Wide special holidays) and one "Service Specific" calendar created by a Team Owner.  

💡 For simplicity we're assuming these calendars operate on a "whole day" basis for one week.

💡 Each day will be handled differently to illustrate a case from the rules above.

The calling customer will experience the service status as follows:

  • On Monday the primary calendar has a "holiday" defined. → The service workflow will react according to the path defined for holidays (usually a closed-announcement), otherwise the default applies (also closed).
  • On Tuesday the primary calendar is default "closed", however the secondary has a special period defined. → In this case the the secondary calendar takes precedence.
  • On Wednesday the primary calendar is default "closed", however the secondary has an "open" period defined. → In this case the secondary calendar "open" period takes precedence.
  • On Thursday the primary calendar and secondary calendar have a default status, but no specific periods defined. → The primary default "closed is used, secondary default gets always ignored.
  • On Friday the primary calendar has a special event type defined. → Depending on how the service workflow is configured, it will react to the "special" primary calendar period (e.g. same as Tuesday).


🔍These values are mandatory Service Level Agreements (SLA) to specify as they are integral part of your team's Reporting and the Nimbus Reporting Model KPI calculation.

SLA Acceptance Time in Seconds

Maximum allowed time in queue before a task (read: incoming call) in the Dashboard is flagged as outside of SLA. 

🔍 Shows as "Acceptance SLA" in both Reporting and historic Power BI reporting. Directly relates to Nimbus KPI Calculations.

SLA Hangup Time in Seconds

Maximum allowed time in which the caller can hang up on a call without it being flagged as outside of SLA.

🔍 Shows as " Hangup SLA " in both Reporting and historic Power BI reporting. Directly relates to Nimbus KPI Calculations.

💡 Hung-up calls will still be considered as failed and thus show up as "Hangup in Queue" (red) in Reporting.

Short Abandons Threshold in Seconds

Maximum allowed time until the call is marked as “Abandoned” in the Nimbus Reporting Model.

💡 Default: 5s, min 1s, max 30s

Show on Historical Sessions Page

Default: enabled. 

GRPR - When disabled, the service and its related task results will not appear in the Historical Sessions view.


TENANT ADMIN Privacy setting - To be compliant with GDPR regulations and respect Nimbus user privacy you can hide the "User Statistics" widget from the Service's respective Reporting view.

TEAM OWNER As service / team owner you may check on this setting, but not change it.

 When enabled:

→ All Nimbus users of this service will not be able to inspect the "User Statistics " > (not) accepted tasks" anymore. This also includes team owners / service administrators.
→ The "Task Heatmap" widget will utilize the remaining space within the Reporting view.

💡 Note that this setting is only affecting the Frontend reporting and not the actual Nimbus Reporting Model backend data. You can still evaluate / anonymize call data within Power BI Paginated Reports.



Modality Service Settings

This tab controls Task Distribution settings per modality (e.g. Audio/Video, Chat), such as your configured Workflows for Call Handling, Chat Handling and External Tasks.

🔍Note that there are different types of workflow per modality, so the pulldowns show different contents. Either workflow type must be created in the Configuration.

Modalities tab

Modalities tab

Configurable Modality Options

💡Available options in this tab depend on the licenses and modalities enabled via Service Administration > General Tab > Licenses. While unlicensed (or disabled on your Tenant), you will see fewer options to configure. The following options can be configured:

Option / Modality

Advanced Routing

Enterprise Routing

Contact Center


Inbound Conversations

Enables this service for the corresponding inbound modality allows you to select an Audio / Video Workflow, which handles incoming calls and video telephony.

Voice Messages Channel

Does not apply as no single Teams Channel manages voice messages.

🔍 This feature only applies to MS-Teams based User assignment types with an Audio / Video workflow applied.

Some workflows can contain "Voice Message " activities that show Adaptive Cards in your MS Teams channel. 

Any existing channel in your Team can be used for voice messages

☝ Note on changing voice message channels: You can change the default voice messages channel at any time. Nimbus will automatically post future voice messages to the new channel. 

Existing messages are not transferred when you switch the channel. Expired sessions or missing permissions may render cards from the previous channel inoperable. → We recommend to downloading your voice messages and/or "solve" your Adaptive Cards from the previous channel before switching, as any content is not transfered. 

Outbound Conversations


The "Outbound Calls" feature allows service members to impersonate and make calls "as" the service itself.  


🔍Learn more on Outbound Service Call / Call On Behalf.


🔍 An Outbound task will show up in Supervision Personal Dashboards and within the " Service Outbound Tasks Tabular" Dashboard Widgets .

Instant Messaging


 (Private Preview)



This feature requires both Contact Center service license and Interact to operate. 


Enabling the IM modality allows you to select an Instant messaging Workflow. Learn more about Chat Handling to see how settings affect users on both ends.


You can also assign Admin-Configured Service System Messages to customize the chat experience and default texts for your service users and customers.

External Task



Learn more on by visiting External Tasks.

Good to know

  • Modalities and options available may differ on your Nimbus instance and individual service, as they may be disabled on tenant level or reliant on service Licensing. If you have any questions on licensing and Nimbus Features, don't hesitate to contact your Luware Customer Success partner.
  • Workflows are only shown as previews. To edit the source workflow, head over to the Configuration and create / edit a workflow in the corresponding modality. ☝ On productive services we strongly advise to work with a copy and switch over when you are done.

Switching between Workflows

All Modalities This chapter applies to all modalities in this tab. Workflow pulldowns change available – and previously configured – per modality. The selection is depending on the respective workflow type and Organization Unit of your service. Before switching, please carefully read the advice below!

Switching a workflow to handle "External Tasks"


WARNING: Clicking "Save and Apply" will apply workflow-related changes with IMMEDIATE effect for all further incoming tasks (calls) on that service. An incomplete or erroneously configured workflow may cause interruptions to your daily service, including lost calls!

💡 Rule of thumb: All Task Distribution in Nimbus will be done via the workflow a task was originally created with. As you confirm changes, already queued tasks will not be directed to the new workflow.

🤔 How can I minimize disruptions to my services?

→ Head to your Configuration > Workflows and check via the list if your workflows are shown as "Used in service". Note that multiple services can use the same workflow.     
→ When you need to do immediate changes, we recommend creating a workflow copy (e.g. calling it V2, V3, etc), then switch over once you are satisfied. By doing so, you can review changes first – e.g. by testing the workflow in a non-productive service – then switch over all your services to the new version.

Configuration > Workflows - inspecting where workflows are used and creating copies as needed

✅ Additional precautionary steps:

→ All your experimental workflows should be moved into Organization Units where productive services cannot opt into them. Think of this as a protected "OU-folder" that is out of sight of any service owner. In the same fashion you can also place other configuration items and services under that OU until they are ready.     
→ Especially on productive services with a high volume of tasks we recommend to perform any workflow switches outside productive business hours to minimize any potential impacts.



Distribution Service Settings

Contains settings related to call distribution.

🔍 Note that - once applied - these settings affect all current or future users in this service.


Allows to configure settings that affect Nimbus user status handling and call distribution.

User Assignment Type

Shows how (new) users are assigned to this service. → See User assignment types.

💡 The default for Nimbus is "Microsoft Teams Based". Users are directly synched to the Teams channel related to the current service.

🤔 Why is this setting locked? The assignment type is determined during Service Provisioning.

Distribution Policy

Contact Center Service Type feature.

🤔 Why is this setting locked? Distribution Policies are managed and changed via the Service Administration, depending on your service type and licsense.

New users immediately active

The " Active"  setting determines if Microsoft Team "Members" are considered as users for Nimbus call distribution. Enabling this feature will automatically add new team members to your Nimbus service team.

An "Active" state has the following effects:

  • Only "Active" users may receive Nimbus distributed calls. Users may still be part of a team but remain inactive for the team's designated Nimbus Service.
  • Team Members that are set "Active" at least once in a month will count into statistics of the Nimbus Administration
  • Active Members are immediately part of the Nimbus task queue distribution according to the set Workflowsand may handle calls for the service team.
  • They also appear as "Active" in the Dashboard for all other team members.


  • Both Team Owners and Team Members themselves can toggle their "Active" state at any time within either the My Services tab of the personal Nimbus app or the Team Dashboard >"My State" widget.
  • Toggling this state acts as a quick "gate" to opt-in and -out of multiple Nimbus Services in case you want to balance your personal customer interaction as user and Nimbus capacity per service team.
  • In addition to the "Active" state the "User Presence" (within Teams) also needs to be in a state that allows for call distribution → se

Conversations Distribution

Determines call distribution based on user presence state as set in their MS Teams client.

✅ Precondition: Regardless of Microsoft Teams IM presence, a user always needs to be "Active" in the service to receive Nimbus distributed calls → See above.


On the My Services dashboard a user will be shown in state: "(Not) Availableaccording to the configuration above:


💡 When a user is part of multiple teams and already taking a call for one service line, the user is also marked as " Not Available " in all other Nimbus teams.

💡 IM presence states considered by Nimbus are:

  • Available
  • Busy 
  • Do Not Disturb
  • Away
  • Offline

Whenever you make adjustments to your Distribution we also recommend checking the following:

Workflows - as activities inside - such as "Availability-based Routing" or "Queue" will affect call distribution, reaching more or fewer (active) users respectively. MS Teams presence is also re-evaluated depending on the "Distribution Type" setting in the "Queue" workflow activity:

"Queue / " workflow activity Distribution Type setting Availability Scenario Effective Task distribution

Broadcast When a user turns back to "Available" and a broadcast task is in the queue. During the next distribution iteration (timeout criteria or decline by other users) the user is included for distribution.
Direct When a user turns back to "Available " and a direct distribution task is in the queue. During the next distribution iteration (e.g. RONA criteria or decline by previously selected) this user included for distribution.
Pickup When user is "Not Available" Pickup controls are disabled (e.g. in Dashboard)

During the next distribution iteration (e.g. RONA timeout) this user included for distribution.

💡 A message will be shown on mouse-over that the IM presence is preventing task handling.

None, see node exit ► No One Available Currently all users are inactive (or active but set "offline" in MS Teams)
None, see node exit ► In Time Available Currently active users are not immediately available e.g. "DND/Away/Busy" or when occupied by another call.
None, see node exit ► Direct Available Currently at least 1 user is available = MS Teams presence set "available" and also set to "active" in Nimbus).

Reporting Settings  (Settings > General > Reporting ) - as user related distribution and availability changes can directly affect your reporting SLA.


Task Priority

Contact Center Service Type feature. The Task Priority determines how incoming calls from this service are handled in sequential order.

Configurable Property Description Behavior What it looks like
Task Priority
  • Strict*
  • Highest
  • Very High
  • High
  • Normal (Default for Services)
  • Low
  • Very Low
  • Lowest
  • Nothing Else*

* see 🤔

When a new task enters the to the queue, it gets a priority according to the service setting:

  • Tasks are distributed according to your currently applied Distribution Policy (e.g. "Longest Idle" or "Most qualified" users first).
  • The order of Tasks is handled by priority, meaning: 
    • A new task of higher priority over existing tasks will take precedence and be handled as soon as possible.
    • A new task of equal priority will be sorted in below already existing tasks of the same priority, as it entered the queue at a later point of time.
    • A new task of lower priority will be sorted "in-between" higher priority task rounds, using a weighted round robin method. → See chapter below.

🤔 When should I select "Strict" or "Nothing Else" as my priority?

  • "Strict Tasks" will always be put on top of your queue. Use this for Emergency services and important VIP hotlines that always should get precedence over anything else in your queue.
  • "Nothing Else" Tasks will only get distributed when your service queue is empty.

☝ Note that selecting either "Strict" and "Nothing Else" will ignore round-robin distribution. Tasks get lost due to potentially long queue times.

In views with a task list (e.g. My Overview or Personal Dashboards with "Task" widgets) a "Priority" column indicates how high this task is ranked in the queue. With this setting, tasks may now "displace" existing tasks to a new rank.

Weighted Round Robin Task Distribution

Due to the rules above, task may "starve" for very long in a queue. An example would be a "Lowest" priority task getting outranked by higher priority tasks. To avoid this, a weighted round robin method is in place to mix in lower-priority tasks, equally distributed amonst available users:

Learn more...

Q: Calls in Queue | H: Handled | R: Remaining

Priority Q H R H R H R H R H R H R H R H R H R H R H R H R H R H R H R
1 (high) 12 2 10     2 8         2 6     2 4         2 2     2 0        
2 (med) 6     1 5     1 4         1 3     1 2         1 1     1 0    
3 (low) 3                 1 2                 1 1                 1 0
Round Counter Round 1 Round 2 Round 3 Round 4 Round 5 Round 6
Time (t) t1


The Round Robin procedure distributes the calls in such a way that the ratio between the individual priority levels is always 2:1. Each time another "Round" is started, that round counter is applied to the "weight" of the remaining tasks.

The example above assumes a configuration with 3 priority levels. There are 21 calls in the queue, with the following priority:

  • 12 calls with priority 1
  •   6 calls with priority 2
  •   3 calls with priority 3

Following the 2:1 rule, the calls are queue over time t as follows:

  1. Round 1: High Med tasks added in 2:1 ratio.  No "Low" priority tasks in Round 1 as "Medium" task count outweighs the low task count.
  2. Round 2: High Med Low tasks added in 2:1 ratio. The "Low" priority  tasks get a round-multiplier added to their weight, now outweighing "Medium" tasks and thus are added in a 2:1 ratio.
  3. Round 3: Same as Round 1.

🔍 Sources: Weighted Round Robin (Wikipedia Article)Please note that this example only works as long as no new calls are being processed. Calls with strict or no priority are not considered in this rule.


Task Priority in "Queue" workflow activites

In a multi-service environment, the "Priority" setting effects your "Distribution Type" setting within a Queue Workflow Activity:


2 Services A&B using a "Broadcast" Queue Activity setting in their Workflows.


  • Service A : Broadcast, Calling Timeout - 30, priority "Low"
  • Service B: Broadcast, Calling Timeout - 30, priority "High"
  • Both services pool the same 10 users, Active and Available
  1. A first (low) call to Service A will block all 10 users with the call invitation.
  2. A second (high) call to Service B enteres the queue. All users are still blocked for the 30s timeout.
  3. The first (low) call is declined by 1 user, which then immediately gets the second (high) call distributed. 
  4. All 9 users are still blocked by the (low) call engagement until it is handled.
  5. Only the 1 user finishing the (high) engagement may take the next (high) priority call.
💡 The "Broadcast" Queue setting is fixed to a 10-user batch. In a Priority scenario the first call entering – even if lower priority – may block higher priority tasks.

After Call Work (ACW)

Contact Center Service Type feature. ACW time (in seconds) is added to the end of a call session until the user is considered available again to take the next task.

Option Description ACW in Portal UI View
Enable ACW Time

When enabled, shows ACW in both My Sessions and Assistant in the Nimbus portal.

💡 Once enabled the default ACW time (02:30 mm:ss) is granted. Can optionally be extended or stopped with the additional options below.

Allow Early End

Enables all Nimbus users of that service to stop the ACW counter at any time.

→ Stopping ACW will free up the user to become "Available" within Nimbus and receive the next task / call.

Allow Time Extension

Enables all Nimbus users of that service to extend ACW by the amount specified in the " Maximum ACW Extension Time ".

💡 This time is granted as flat "new" value to the user, not added to any remaining ACW time.


  • When a user goes offline in Microsoft Teams it will terminate the remaining ACW time for that user.
  • Changing the ACW Toggle / Time in settings during productive hours will have an impact on new (incoming) Tasks only.
  • Users are blocked from all other Nimbus service calls during ACW.
  • ACW is also tracked in Power BI for reporting purposes. Reports ACW time in seconds or "Null" if disabled. Total ACW time in a single service session is summed up from all involved user sessions.


Contact Center Service Type feature. RONA (Redirect On No Answer) is a "not selectable / available" User State for all type of services. A Nimbus user in MS Teams is given RONA status if they ignore a service call or do not answer it within a set period of time seconds.

💡 The RONA status ensures that the call doesn't get lost and is instead redirected back to the queue (or handled otherwise via the Workflow). RONA is also tracked in the Nimbus Reporting Model, and can be evaluated via Power BI OData interface.

🔍 This status does not apply when the Distribution Type in your Queue Workflow Activity is set to "Broadcast", as it would otherwise flag entire batches of users with RONA status when a call doesn't reach them.

You can configure RONA as follows

Element Description
Persistent RONA 
(toggle, default: disabled)

Adds a persistent RONA state to any Contact Center licensed users of that service when they fullfill either of the following criteria:

  • Decline a call from that service
  • Ignore a call invitation from that service

🔍 While in RONA status the user is considered as "Not selectable / Available" by Nimbus and will not receive further call invitations. → See note below.

RONA Reset Time

RONA Reset Time (must to be specified)

    • hh:mm:ss format
    • Default 10min
    • Min 10 sec to Max 320 min (8h)


An already active RONA state can be reset as follows:

  • Automatically, after the specified "RONA Reset Time"
  • Manually by the user via Assistant (both portal and standalone). An count-up timer shown next to a manual reset button.
  • When the user goes Offline in MS Teams.
  • When the user switches to an "Off Duty" Profile.

💡 Changing the persistent RONA flag to false or changing the reset time will not have an impact on already set RONA states.



Extension Service Settings

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


Please note that some extensions will only be fully configurable when you have the according license applied via the Service Administration. Refer to Nimbus Features for an overview and get in contact with your Nimbus sales contact if you require a demonstration.



✅ Primary and Secondary Codes must be configured beforehand and available within the service's respective service Organization Unit before they appear in this list.

🔍 Codes will be stored as part of historic reporting and available via BI Template. → More details on "Codes and Tags Below below.


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.
  • Re-use or define specific conversation context context opened as the call is ringing or accepted. By doing so, users do not need tohave 

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

Within a Service you can configure context for Assistant individually as follows:

Target Audience What can be applied How to Configure
For 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.

For 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

Enterprise Routing Contact Center Allows you to enable or disable My Sessions view which provides caller information and context during an ongoing or concluded call. 💡 Note that certain Features require either an Enterprise Routing or Contact Center license on the service.

Conversation Context

Conversation Context must be configured beforehand and available within the service's respective service Organization Unit before it appear in this list.

Conversation Context items can open in an extra tab or widget whenever a service call is accepted. Additionally, the My Sessions view in Nimbus allows to open context as an embedded context widget, e.g. to provide further caller information or to provide further functionality within a ticketing system.

Possible use cases for context could be:

  • Create, update or open incident tickets in your based on incoming call information.
  • Provide additional help or instructions to your Agents, based on the called services.
  • Extend the call scenario with further browser-based applications such as CRM, SAP or custom-developed apps.

Considerations and Preconditions

The following points need your consideration before using context in Nimbus:

Context tabs require your browser

✅ To open context in tabs during active calls, your Nimbus Personal App must run in your browser.

💡 The Nimbus Teams Tab within MS Teams cannot open context by itself. → Within MS Teams you can open Nimbus via the "Go to Website" Icon located at the top right of your Nimbus app.

💡 Good to know: An installed Assistant on your local PC can open your browser and related context via the use of Service Call Templates.

Open Nimbus in Browser

To access the portal you can also use any of the following links: 

Portal URLs:

✅ Make sure to configure your web proxies to allow access to these domains or whitelist the complete * domain.
Context requires pop-up blocking to be disabled

Context may get blocked by your browser. Make sure that Microsoft Teams and Nimbus URLs are excempt from any pop-up blockers.

💡 Some browsers block pop-ups as a default. You may need to do one test call to see and allow the blocked pop-ups.

💡 Your company IT policies, Ad-blocking addons or browser specific settings can also provent opening of context. If the problem persists, talk to your system administrator.


Pop-up warning from Microsoft Edge


GDPR By default disabled. Context data (including custom Parameters used in Conversation Context items shown the My Sessions widgets will not be stored after a service session has concluded.   
→ In result, the caller information of any historic call record will not be shown and previously working custom parameters (e.g. to open a customized context URL for a ticketing system) will not resolve anymore.

When this is enabled: 

  • Call context information data is stored per service session on call termination.
  • If there was service transfer, context information for each service session is carried over. 
  • The following is stored per session:
    • Custom (user created) Parameters
    • System Fields and Parameters   
      • Customer "custom" parameters
      • "System" parameters (like call id, service upn, etc)
    • Default "My Session Parameters" user data is not stored as it is retrieved dynamically from the internal user directly of your Tenant.
  • On historical (concluded) sessions within My Sessions...    
    • ... the "Embedded Context widget" will resolve the currently configured URL with a previously saved call information.
    • ... the "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.

Data lifetime:

  • If caller info is updated on a terminated even and stored for 30 daysfor the last available service session (in case of transfers).
  • Conversation context data will also be stored for failed/killed calls.
  • After 30 days the data is cleared. This also happens when the service or tenant is being unprovisioned.

🔍 Learn more about the Nimbus data handling policy in the whitepapers available in the Documents section.



The following widgets can be configured: 

Setting Description
Codes and Tags

Contact Center Enterprise Routing

Enables a "Codes & Tags" widget in the My Sessions view. 

✅ Primary and Secondary Codes must be configured beforehand and available within the service's respective service Organization Unit before they appear in this list.

💡 Tags can be freely defined by users during incoming calls. Suggestions will be auto-completed based on previously provided tags.

Defining Codes

Codes and Tags in the MySessions view
Contacts (and Search)

Enables a "Contact Search" widget in the My Sessions view. During an ongoing call you can perform a search and notify contacts in your Organization. 

Embedded Context

Contact Center Enterprise Routing

💡 Conversation Context must be configured beforehand and be available within the service's respective service Organization Unit before it appear in this list. 🔍 Functionality is the same as described in → chapter Context above. 💡 Please note that only one Context item can be shown embedded per service call.


Example page shown as embedded context in MySessions view


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

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:

What do I need to check?

License Downgrade Checklist

Downgrade from Features that need to be checked / deactivated in order to downgrade

Downgrading from: Things to check

Enterprise Routing

✅ Check Workflow Templates used in your Service Settings that come with Enterprise Routing features.

  • You can either downgrade to simpler template to save yourself the search work, or manually re-configure your existing workflows, e.g. by searching:
  • Workflow Activities which are marked with a licensing constraint (e.g. "Check Parameter", "Check Task").
  • "Pickup " type Call Distribution settings from any "Queue " workflow activity.

✅ Check and disable additional Context, Codes and Tags enabled in the My Sessions view.

✅ Check and remove any additional custom and system Parameters from your Service Settings > "Extensions" tab.

✅ Check and disable Outbound Service Call features as part of the Service Settings > Distribution tab Doing so will remove the corresponding options in the My Overview or My Services view.

Contact Center

On Services:

✅ Check everything from → Enterprise Routing disable related Features.

✅ Additionally you need to... 

On users:

Individual Contact Center licenses can also apply to users. There are two methods to remove a license from a user:

Either remove licenses via the User Administration, or ... 

... head to the "Licensing" overview, search for the user and click "-" to remove the license.
💡 You can also review and undomultiple license changes before confirming with "save".

☝ Warning: Removing a Contact Center license from a user will remove ALL associated settings and service assignments. This action is irrversible, meaning that you must re-define this user if you ever reconsider adding the license again.

💡As an example: a user can have individual Skills and Responsibilities and be assigned to multiple services via Agent Service Settings. Both associations are getting removed alongside with the license . If you want to re-assign or reinstate your Contact Center license at a later point you might want to check on Responsibility Profiles to ensure that the licensed user is correctly queued, according to your (remaining or new) service's Distribution Policies .

🤔 Why isn't the license downgrade automated? As features such as skills and workflows may be used accross multiple services, simply removing them is not an option. A manual check ensures that features are conciously removed and don't render your remaining services unreachable, e.g. due to suddenly disabled workflow activities or missing parameters required for call routing.

🤔 I have finished my checks. What comes next? Once the steps are done g et in contact with your service partner or Luware support to downgrade your license.

Session Details

By default the My Sessions "Session Details" widget displays a set of of default parameters which are retrieved and shown during an incoming and active call. With the "Session Details" settings you change these entries order of appearance and greatly expand the available information.


My Sessions view showing additional Session parameters in a custom order

🔍 Good to know: Please note that session detail settings are are available to all services – with additional features provided based on your service license. Refer to the table below for more details.

Service License Available Parameters
Advanced Routing

My Session Parameters. A list of default parameters available to every "My Session" view.

  • Default entries are: Display Name, Phone and Moble numbers, Email, SIP Address, Company and Department of the caller.

💡 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 Center

Additional System and Custom parameters for your "Session Details" become available with an Enterprise Routing or Contact Center license on your service:

An example mixture configuration of My Session, System and Custom Parameters


  • Any custom / writable parameter information is only updated when previously retrieved from an external directory, e.g. by using the Microsoft Power Automate Connector. For privacy and security reasons, parameters records are not stored by Nimbus, and cleared after a call / service session has ended.
  • Note that your Custom Parameters can also be referenced via Workflows, depending on the service being called. Services can make use of the same parameters to standardize the looks of the Session Details within My Sessions.

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.


 Learn more...

License downgrades can be performed from within the Licensing overview. However, when Nimbus Features are already in use, a warning will be shown:


Checking for downgrades in the "Licensing" view

🔍 To downgrade from a higher tier license, any related Nimbus Features and their data entities must be removed or unassigned from the user or service. This is done via Service Administration and User Administration respectively. Refer to the License downgrade checklist below for details.

Tooltips will inform about the settings that prevent a license downgrade.


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.

🔍 Please note: Map locations are only shown when previously retrieved from an external directory, e.g. by using the Microsoft Power Automate Connector to look up a name and address of the caller.



Permission Service Settings


Contact Center feature. Contact Center licenses are required both on the Service Administration and User Administration. Once enabled, the “Agents” view 

For Tenant Admins: The Permissions tab becomes visible in the Frontend when the Service type is set to Contact Center (skill-based distribution). Users  (Agents / Owners ) are assigned from the Admin UI assigned via Service Permissions.

User Skills and Levels need to be configured as assignable items first before they can be assigned to Agents. Refer to our Use Case - Setting up a Contact Center for a full walkthrough.

🔍 Note: Services of User assignment type "MS-Teams based" will show a “Users” tab instead. → See User Service Settings.

For Team Owner:  On the Portal the Agents tab becomes visible when your service has Contact Center Features enabled and users assigned as Agents.

A listing of Agents and Owners in a Service with corresponding editing options

Editing Agents

Any service owner can access the Agents tab to adjust the levels of Skills and Responsibilities of Agents assigned to that service. 

Active Profile

Acts as the equivalent to the toggle, available in the Assistant app.


Edit (Skills / Responsibilites)

Allows adjustment of Skills and Responsibilities for each User. 



Please be aware that profile edits on users have potential widespread effects:

  • Responsibility Profiles of Agents are considered by any skill-based service for the distribution:
    • If no skills are assigned or responsibilities change, the user may not be selectable for calls.
    • Changes immediately affect all services that the Agent is assigned to via role / permissions .
    • Skill and duty changes are made on the user itself. They are visible to other admins and service owners with view / edit permissions on this Agent.
  • Distribution Policies set in each service's Settings > Distribution tab will reflect Agent skill and responsibility changes immediately as the next call arrives.

💡 An example for skills / responsibility levels:

  1. An Agent is part of 3 services A, B and C but their skill levels currently allows distribution only according to the Distribution Policy set in service A.
  2. You decide to raise that Agent's language proficiency level. → Service B requires that level and will now consider the Agent as well.
  3. You do not need the responsibility and decide to deactivate it. → Service C's distribution policy however relies on it and will still not consider the Agent despite the higher skill level.
  4. The owner of service C will add a completely new skill to this Agent and reactivates responsibility at the same time. The next time you edit this Agent, can see this change reflected.

☝ Important: If you share Agents between multiple team owners, coordinate your changes to their skillsets and responsibilities. Refer to the Distribution Order page for more details.





Interact Service Settings

💡 Interact allows customers to directly communicate with your service agents via website, without the need to install or run a chat client on their side.


  • TENANT ADMIN Interact is a feature enabled on tenant level.
  • Once configured Interact allows customers to reach a service directly from external URLs (websites) via small chat or voice widgets.
  • The Contact Center license needs to assigned to a service for the "Interact" settings to become visible. See Service Administration > General Tab > Licenses.

Features described in the following are still in beta (experimental) stadium.

 Learn more...

  • Features marked with are still being evaluated in both performance and usability by both our users and the development team.
  • Notable limitations and bugs may occur. An experimental feature may be temporarily disabled as improvements are implemented.
  • Based on customer feedback, scope and design of the feature may change significantly in upcoming updates.

Editing Interact Service details

After the service has been granted an Interact license the Interact-tab for further configuration will become visible.

An example configuration for a service

The following options can be configured:




✅ This feature needs to be enabled for your Tenant, see prerequirements above.

💡 Note that Interact licenses (granted via "General" Tab) remain active for this user.

Audio & Video

When enabled the service can be contacted via call modality using Interact. Also refer to Call Handling.

💡 Regular Nimbus distributed service calls will still reach this user despite of this setting.

Instant Message

When enabled the service can be contacted via chat modality using Interact. Also refer to Chat Handling.

💡 Regular Nimbus distributed service calls will still reach this user despite of this setting.

Restrict Access

Toggle that applies Interact Domain Templates (CORS) as "whitelists"

  • When enabled, web page access to this service is limited to domains specified in the CORS templates. 
  • When disabled. any web page may access the service.
Domain Template Lists Interact Domain Templates (CORS) available under the same Organization Units as the current service.
Service Snippet

Default script with settings of current Service, which is later can be inserted into a the web page and used as a contact widget.

☝ Please note that the "Contact ID" and "WidgetKey" are unique to the current service and should not be mixed.

💡 Use the "Copy" button for easy Snippet Code retrieval.











Table of Contents