Service Settings

An overview of all Service Settings Tabs.

Good to know

Service settings are available Nimbus service / team owners. You can access them via Nimbus Portal:

Settings in Main Menu
Settings in the Service Overview

Also Note: 

🔎First time to Nimbus - Read this?

Being new to Nimbus and its many settings can be daunting. For this reason we set up a series of Administration Use Cases for a convenient step by step introduction. 

As a first entry we recommend: 

More Advanced: 

🔎 Shared Concepts:

  • Nimbus Settings rely on shared entities (e.g. Workflows, Playlists, Opening Hours) - all managed via Configuration. We highly recommend checking there first before adjusting your settings to avoid having go back-and-forth.
  • Visibility of options available in your settings is determined by Organization Units (OU). 
  • Access to Nimbus Features may be hidden from your view based on your Role and the assigned License Management  
  • To reduce complexity, settings may be hidden as licensing or Nimbus Features must be enabled first.
 
 
 
 

Service Settings Tabs

🔍 The tab 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

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

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.

CHANGING A SERVICE DISPLAY NAME

  • 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?

 

PSTN

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.

RULESET: PRIMARY AND SECONDARY OPENING HOURS

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

Reporting

🔍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 in a queue without the call 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 (queue time) until the call is marked as “Abandoned” in the Nimbus Reporting Model.

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

☝ The timer starts when the Nimbus bot accepts the call. The threshold counts, regardless where the customer hangs up (e.g. in IVR or Queue). As soon a accepts, a User Session (in the Reporting Model) is established and the call is not considered as “short abandon" anymore.

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.

GDPR - HIDE USER STATISTICS FROM REPORTING

Tenant Administrator 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 a 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 and service administrators.
→ The "Task Heatmap" widget will utilize the remaining space within the Reporting view.


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

 

Licenses & Addons

In these sections, you can assign licenses and addons to the service. Available tabs and settings depend on the assigned licenses/addons, as explained under License Management and the related Nimbus Features pages.

 
 

Modalities

Modalities Service Settings

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

🔎 Good to know

Note that there are different types of workflows per modality, therefore the pulldowns show different content. Either workflow – regardless of Modality — must be created in the Configuration.

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.

☝ Note that Workflow changes are immediately effective! On productive Services we strongly advise to work with a copy and switch over when you are done. → Also read the note on the bottom below.

 

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:

Modality1 & Features 

Advanced Routing

Enterprise Routing

Contact Center

 Description

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 Services with an “MS Teams” type User assignment and an Audio / Video workflow applied. 

  • In MS Teams the Service will use a dedicated channel for voice messages. 
  • Workflows can use activities like "Voice Message" that show Adaptive Cards in your MS Teams channel. 
  • You can change this default. Nimbus will automatically post future voice messages to the new channel.

Learn more…

 

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

☝ Note on changing voice message channels

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

 
 

Outbound3 Conversations

-

When enabled, the Outbound Call feature allows …

Outbound3 with Workflow - -

Contact Center Precondition: Service Owners must use the “Schedule an Outbound Call with Workflow” Flow Action to schedule the call.

Enables this Service for Outbound Call with Workflow. Switching the toggle on allows you to select an Audio/Video workflow.

Instant Messaging

-

-

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

-

-

Allows services to handle the External Tasks modality.

💡For more details on how this looks for Nimbus users, visit External Task Handling.

Email - -

Allows services to handle the Email modality.

💡For more details on how this looks for Nimbus users, visit Email Handling.


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

2🔍A scheduled Outbound Task (Call) will show up in Supervision Personal Dashboards and within the " Service Outbound Tasks Tabular" Dashboard Widgets.

3🔍Common preconditions and technical Limitations apply: Please visit the Outbound Call page for more details.

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!

Enabling and selecting a workflow to handle "External Tasks"

WORKFLOW CHANGES DURING SERVICE HOURS


ATTENTION: Clicking "Save and Apply" after workflow changes has an IMMEDIATE effect for all future incoming Tasks for that Service. An incomplete or erroneously configured workflow may cause interruptions to your daily Service, including lost calls!


💡 Rule of thumb: Task Distribution in Nimbus starts at the moment a task was originally created with. As you confirm changes, already queued tasks will not be affected by 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.

The “Used in Service” columns indicates in which Settings a workflow is currently applied and effective.

✅ Additional precautionary steps:

→ Especially on productive Services with a high volume of tasks we recommend to perform any workflow switches outside your productive business hours to minimize any potential impacts.
→ Any experimental / work-in-progress 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.     

 
 
 
 
 

Distribution

Distribution Service Settings

Contains settings related to Task Queue and Distribution, affecting factors like User States, Task Priority, and additional blocking status effects like After-Call Work and RONA.

☝ Note that confirming changes on these settings immediately affects all Users and future incoming tasks of any modality. 

✅You may want to adjust General Service Settings > Reporting > SLA timings alongside, depending on how you expect your shown Reporting metrics to be affected by stricter or more lenient distribution settings.

 

Users

Allows to configure settings that affect Nimbus User States handling and task distribution.

User Assignment Type

INC User Assignment Types

Each Nimbus Service can be of a different User Assignment Type that determines how Users are associated to this Service:

  • MS Teams-based: Directly tied to the Team itself in MS Teams, determined during Service Provisioning. Users get automatically added and synced to a Nimbus Service.
  • Skill-based: Applies for manually created Services via Nimbus Service Administration. Requires skill-assignment to Users you manually assign to the Service from within your Tenant directory.
  • None: Primarily used for IVR or first-level redirection Services. This Service has no Users and is therefore primarily configured by any Administrator.

☝ Important to know: The User Assignment Type setting is fixated when a Service was either provisioned via MS Teams or manually created via Service Administration, e.g. either for Customer IVR or User skill-based task distribution purposes. A switch between MS Teams-based and Skill-based Services is not possible due to how individual Users are configured and how related Nimbus Features operate.

 

🤔 Why is this setting locked for me? The User assignment type of a Service gets determined when a Service gets created (e.g. within MS Teams or manually in the Service Administration. Changing this setting is only is allowed for Services that are not MS-Teams based.

Distribution Policy

Contact Center license Nimbus Feature.

Distribution Policies determines which Skills and Responsibilities apply to Contact Center Users (Agents) in order to meet selection criteria for your Service. 


✅Related configuration steps: 

New Users immediately active

💡Applies to MS Teams-based Service Types only. The "Active" toggle determines if Microsoft Team "Members" are considered as Service Users for Nimbus call distribution. 

☝Enabling this feature will automatically add new MS Teams members to your Nimbus Service team.


💡An "Active" state has the following effects:

  • Only "Active" Users may receive Nimbus distributed calls.
  • Users that are set "Active" at least once in a month will count into statistics of the Nimbus Administration
  • Active Users are immediately part of the Nimbus task queue distribution according to the set Workflows, and as such may immediately receive and handle tasks for the Service team.
  • They also appear as "Active" in the Dashboard for all other team members.

GOOD TO KNOW: Active UI toggle

At any time both Team Owners and Team Members can toggle their "Active" state within either the Services Overview tab of the personal Nimbus app or the Team Dashboard >"My State" widget.

Toggling yourself “Active” or “Inactive” for different teams via the Nimbus Portal

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.


🔎Related Setting - Distribution: In addition to an "Active" state the MS Teams Presence Status also needs to match the criteria of the “Conversations Distribution” section below. Otherwise Users will not get Nimbus tasks.   

 

Conversations Distribution

These Settings determines call distribution based on MS Teams presence set in the User's 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. Further User State factors may also result in the user being shown as “Not available” → 🔎 More on this below in the Notes.

MS Teams presence states considered by Nimbus are as follows:

MS Teams Presence Nimbus distribution behavior
Available The default task distribution behavior for Nimbus. Users need to be Signed-in and Available to receive tasks.
Offline (and “Appear offline”) No tasks are distributed to Offline Users.
Do not Disturb (DND) No tasks are distributed to DND Users.
Busy (in a call / meeting)

Optionally configurable: Allows Nimbus to distribute tasks to Users even while Busy.


✅ Tip: By default Nimbus can only detect a high level “Busy” status. When Use Case - Tracking Extended User Presence via Application Permission is implemented, a more distinguished presence tracking is possible, for example allowing to still distribute calls when “Busy - In a Meeting” instead of just being shown “Busy”.

Away Optionally configurable: Allows Nimbus to distribute tasks to Users even while Away.

🔎Good to know: Preferred / Lasts User Routing

Contact Center Services may enforce Distribution Policies that allow them to have Users defined as “Preferred User Routing” and “Last User Routing” targets. As these Users do not need to be part of the Service, Distribution Settings above will be ignored. 

 

How it looks in the UI

As an example on the Services Overview a User will be shown in state: "(Not) Availableaccording to the configuration above. This User State is a result of:

  • The User being “Available" in MS Teams
  • The User set to “Active” in Nimbus

🔎User States and Multi-Service participation

Being “Selectable” for tasks depends on the existing User State, which is considered by all Services that may target the same User. The User State includes MS Teams presence, but also other factors.

💡Here are example scenarios: 

  • When a User is part of multiple Services and already taking a task, the User is also marked as “Not Available” in all other Nimbus services.
  • However, when the user has Task Parallelization enabled, they can Park the first task, which in turn sets them “Available” for the next Audio/Video task, which can be distributed by any other team.
  • Aside from MS Teams Presence blocking tasks, additional Nimbus status flags can also prevent task distribution. Examples are RONA status set to the User when not responding to a previously assigned task, or the User still being busy in ACW from the previous task.
 

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

Workflows

Workflows  or more specifically Activities such as "Availability-based Routing" or "Queue" – will directly affect call distribution, reaching more or fewer (active) Users respectively. The MS Teams presence is also re-evaluated when the corresponding Workflow Activities are reached.

“Queue” Activities 
(Queue / Queue Task)
Distribution Type setting Queue distribution behavior

Broadcast To all "Available" Users, the task is in the queue is broadcasted simultaneously.
Direct To the longest idle "Available " User, whenever a direct distribution task is in the queue.
Pickup When User is "Not Available" Pickup controls are disabled (e.g. in Dashboard)
Check Activities 
“Availability-based Routing”
Availability exit Activity exit behavior

No One Available Currently all Users are inactive (or active but set "offline" in MS Teams)
In Time Available

Currently active Users are not immediately available when: 

  • in presence "DND/Away/Busy"  (based on → Conversations Distribution Settings above)
  • Are occupied by another task OR
  • Have reached their maximum number of parked parallel1 tasks.
Direct Available

Currently at least 1 active User is available and meets all of the following criteria:

  • MS Teams presence meets criteria (based on → Conversations Distribution Settings above)
  • Has capacity to handle additional tasks in parralel1 when a first task is already parked.

1🔎Applies only when Task Parallelization is enabled. Note that the Activity “In time available / direct available” exit behavior differs per modality. Refer to the Check Activities > “Availability-based Routing” documentation for details

 

Task Priority

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

INC Distribution Priority

Configurable Property Description Behavior
Priority
  • Strict*
  • Highest
  • Very High
  • High
  • Normal (Default)
  • Low
  • Very Low
  • Lowest
  • Nothing Else*

* see notes below.

  1. When a new task enters the to the queue, it gets a default priority assigned according to the service's Distribution Service Settings
  2. When the “Distribution Priority” Queue Activities step is reached, the priority can be redefined. 
    💡 For example use “Special” Opening Hours cases to re-define the priority again.
  3. The order of tasks is distributed via round-robin method. Effectively this means: 
    • 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.

When to select "Strict" or "Nothing Else" as priority?

“Strict” tasks will always be put on top of your queue. 
 ⮑Other tasks can get lost due to potentially long queue times as “Strict” tasks always take precedence.  
✅ 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. 
 ⮑These tasks can get lost due to all other tasks taking precedence.  
✅ Use this for non-time-sensitive tasks in when your maximum queue time is long enough for them to get handled.

 

Priority in other Nimbus areas

  • Whenever certain workflow Trigger Event criteria are met, certain Flow Actions from the Nimbus Power Automate Connector can also be used to set a task priority dynamically. ⮑ This is overriding the default priority set in the Distribution Service Settings.
  • In general, tasks are always distributed according to a service's Distribution Policy (e.g. among "Longest Idle" or "Most qualified" Nimbus users first). 💡 Priority does only affect WHEN a task gets distributed, the policy determins WHO receives it first.
  • In all Nimbus views with a task list (e.g. My Overview or Personal Dashboards with "Task" widgets) "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.
A set of Nimbus tasks shown with different priority
 

Task Priority in Workflow Queues

In a multi-Service environment, the "Priority" setting effects your "Distribution Type" setting within a Queue Workflow Activity. Let's explore this with an example configuration of two services A and B:

Scenario
Setup
Outcome

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

 

Service A : Broadcast, 
Calling Timeout - 30,
priority “Low”
  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 enters 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.
Service B: Broadcast, 
Calling Timeout - 30,
priority “High”
Both Services pool the same 10 Users, which are Active and Available

💡 Learning: 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

Contact Center Service Type feature. After-Call Work time - or in short 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.

ACW in Portal UI View
Option Description
Enable ACW Time

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

💡 Once enabled the default ACW time (default 20s) 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.

🔎ACW Notes

  • When a user has Task Parallelization enabled in their General User Settings, ACW will not apply to them.
  • 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.
 

RONA

RONA

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 state if they ignore a Nimbus task or do not answer it within a set period of time.

💡Tasks resulting in a RONA status are returned to the queue. The RONA status ensures that the task doesn't get lost and is instead redirected back to the queue (or handled otherwise via the Workflow).

The RONA status flag can be enabled and configured to reset itself after a set amount of time, making the user available again.

RONA Settings

Within the Distribution Service Settings you can configure RONA as follows:

Element Description
Persistent RONA   
(toggle, default: disabled)

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

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

1 While in RONA status the user is considered as "Not selectable / Available" by Nimbus and will not receive further task invitations. → Also see User States.

RONA Reset Time

RONA Reset Time (must to be specified)

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

RONA reset conditions

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 the Duty State “Off Duty”.

💡Good to know

  • RONA changed settings are not retroactive: Changing either “Persistent RONA” or “RONA Reset time” in your service settings will have no impact on already set RONA states on users.
  • RONA is also tracked in the Nimbus Reporting Model, and can be evaluated via Power BI OData interface.
  • RONA is a part of the User States that prevent further tasks to be distributed in parallel, flagging them as “not selectable”.
 

RONA in other Nimbus Areas

The RONA status is affected by a variety of other configuration areas in Nimbus, such as Workflows or User specific settings. Whenever you make adjustments to the RONA timeout, it makes sense to also have a look at the related configuration items below.

Workflows: Queue and Transfer

✅Precondition: Workflows use either “Queue” or “Transfer” activities with configurable RONA parameters.

  • RONA in Broadcast Queues: RONA 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 simultaneously when a task doesn't reach them.
  • RONA Timeout "(Max. Ring Time)” is configured in Workflow Activities, such as Queue, Queue Task and Transfer (to User). 
    A very low-configured ringing timeout may not give Users enough headroom to react to an incoming task before the RONA flag is set.

User Settings: Task Parallelization

✅Precondition: Task Parallelization is enabled for a user.

💡Good to know

  • RONA operates the same for parallel tasks: Same as single tasks, parallel tasks will cause users to be passively flagged with a persistent RONA state, regardless if the user already has a parked session or not.
  • Users can reset their RONA state by unparking a task.
 

Emergency Routing

Emergency Routing allows to forward calls when they can not be distributed anymore due to technical reasons.

☝️ Note: This feature is meant as a fallback during technical analysis of Service degradation/downtime to allow to route incoming calls to a temporary (emergency) number. Calls will be blocked from being handled in regular workflows and distribution, allowing Luware technicians to perform maintenance and analysis. 

💡Note that an “Emergency Case” is engaged and managed by Luware System Administrators. When it applies, Luware support blocks the calls on cluster level. In such case, you will find more information on https://status.luware.cloud/.

 
Auto Redirect in Emergency Case When enabled, calls will be forwarded to the defined destination for as long as the call-blocking case applies.
Redirect Destination

The destination where calls will be forwarded to in case of call blocking. Currently, there are three options for redirecting calls:

  • PSTN number
  • User UPN
  • Service UPN

💡Note the following limitations:

  • Services and Users have to be from the same tenant.
  • The Service should be from a different cluster.
    • The Service can be from another Nimbus cluster or another Service, e.g. Microsoft Teams Auto attendant or Microsoft Call queue.
  • If you have the redirect to a PSTN number, the Service needs to be correctly licensed for PSTN calling.

 

 

 

 
 

Extensions

Extension Service Settings

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.
 
Code selection in “My Sessions” view

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

Defined Primary and Secondary Codes will be made available 
 
 
 

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.

Attendant Console

A single Conversation Context  item may be added to show within Attendant Console. Note that you cannot add more than one Context item at a time, as it wouldn't fit into the sidebar.

Attendant Console Context configuration

Once you select an active session (card) in Attendant, the globe icon appears right-hand side. Clicking it will show conversation Conversation Context within the sidebar. ☝Note that general Website embedding limitations apply (see bottom of this page).

Conversation Context shown in the Attendant console Sidebar during an ongoing session.

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.


🔎 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:

Historical storage of Context Data
 

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

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

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.

Custom Context Parameter transfer settings

☝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.
Diagram: Context-Related Service Settings and how related data gets transferred and updated using Power Automate
 

 

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: All MS Teams Conference calls - e.g. those created during Consultation via Attendant - do not support transfers, which also prevents Context Parameters from being handed over.
    → If you require Context to be transferred, use Blind Transfer or Safe Transfer scenarios respectively.
 

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.

 

Codes and Tags in the My Sessions view

Embedded Context

✅ Preconditions:

Example website shown as embedded context in the widget

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

☝Note that general website embedding limitations apply (see bottom of this page).

 

Companion

Displays a widget to show various Companion related features, further configured in Companion Service Settings:

Transcription

The Transcription feature transcribes call contents using Voice-to-Text capabilities.


✅ Preconditions:

  • Transcription must be enabled in the Companion Service Settings (Companion Tab). Head there for detailed instructions.
  • If enabled with no Companion license is assigned to the user, the error message “Transcription not available. User Transcription License missing.” is shown in the widget.

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.

 
 
 

Live Caption

The Live Caption feature converts ongoing call participant voices directly into text, using Voice-to-Text capabilities. 


✅ Preconditions:

  • Live Caption must be enabled in the Companion Service Settings (Companion Tab). Head there for detailed instructions. Note that Live Caption can only be used with both Live Caption and Voice Transcription enabled.
  • If enabled with no Companion license assigned to the User, a “Missing License” error message will be shown in the Frontend.
 
 

Summarization

Summarization processes the transcript to generate a summary containing the most important aspects of a session.


✅ Preconditions:

 
 

💡Hiding features in the background

If you want to process these features in the background  (e.g. via Power Automate Use Cases), you can toggle it off My Sessions, effectively hiding it from the Nimbus User Portal.

 

Session Details

✅ Preconditions: Basic session details can be shown for any service, but extended license features (→ see below) are available.
⮑ Shows a "Session Details" widget  in My Sessions with a set of of default System Fields and Parameters. This data is retrieved and shown during an incoming task. With the "Session Details" settings you change these entries order of appearance and greatly expand the available information.

Retrieved and non-available parameters shown as “Session Details”

 

✅ Extended License Features: The amount of available Custom Parameters is greatly extended with higher Nimbus Feature license tiers. 

Advanced Routing

Advanced Routing My Session Parameters: 

  • A list of default parameters available to the My Sessions view.
  • Default entries are: Display Name, Phone and Moble numbers, Email, SIP Address, Company and Department of the caller.
Default List of “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 Center

Enterprise 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:

Mixture of My Session, System and Custom Parameters

🔎Notes on Parameters in Session Details

 Any custom/writable Custom Parameter data is retrieved using the Microsoft Power Automate Connector.

  • Your own Custom Parameters can also be referenced via Workflows, and update during Trigger Events depending on the service being called.
  • System Parameters are mostly updated automatically by Nimbus as the Service session progresses.
  • Multiple services can make use of the same Parameters (shared Organization Units) to standardize the “Session Details” widget look and feel within My Sessions.
  • Privacy of Session Details (e.g. between Service Transfers) can be steered via “Store Conversation Context Data” option. By default, the details get deleted after a session ends. More on this can be found on Context Handover.
 
 
 

License Downgrade: 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.

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. 

  • This requires either an external CRM / Directory that associate an incoming UPN/PSTN with the customer to retrieve the necessary fields.
  • System Fields > Call Data > CustomerStreetAddress, PostCode, City, State, Country are read to render the position data on a map.
  • Custom Parameters are not considered nor required.

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

General Limitations

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:

 
 
 
 
 

Users

Users Service Settings

🔍Note: This page covers User settings of “MS Teams-based” services. Users in a “Skill-based” service are configured via "Agents" tab instead. 

 

PRECONDITIONS

All Nimbus services allow User Management, however Advanced Routing or Enterprise Routing primarily operate in sync with MS-Teams. In a Contact Center service, users can be managed manually. More info on this can be found under User Assignment Types.

For Tenant Admins: 

For Team Owners:

  • Within your MS Team Team you need to invite additional members and owners to participate in the Nimbus service.
  • In the “Users” Tab described on this page you can manage the "Active" state of your service members and fellow owners.

💡Good to know: Team Members will not see this tab within the Nimbus Portal.

 
Configuring Users on a MS-Teams based service

Common Settings

Setting Description
Default Team Owner Role

Determines which Nimbus User Role a new MS Teams Channel Owner is granted once he joins the team.

 

💡This field is read-only in Portal. To change this an Administrator needs to access Service Administration > Your Service > "Users" Tab. Read more about this on Service Permissions.

Team member can change the active state

Allows or disallows team members to change their active state. 

Active toggles are in various areas of the Nimbus UI

☝Make sure to coordinate this setting: Other team owners and users with the "Workflow Admin Limited" Portal Role assigned can also change the “Active” state of all team members. → This setting always stays in sync between all users of that service, so make sure to inform your service-management colleagues when you change this behavior. 

Users Table

Table Row Description
Name / UPN

💡 Fields are read-only. Users are auto-synced via MS-Teams.

Name and UPN are both fixed and in sync with your local Tenant user directory. To change or correct any of these fields you need contact your Tenant Administrator.

Role

Determines which Nimbus Portal Roles a new MS Teams “Team Owner” is granted once he joins the team.

 

💡This field is read-only in Portal. To change this an Administrator needs to access Service Administration > Your Service > "Users" Tab. Read more about this on Service Permissions.

💡Note: These Portal Roles are only for Nimbus functional and service data access purposes only. Changing them does not change any functionality within the native MS Teams client itself.

Active

Steers the user's availability to take tasks within Nimbus.

  • When enabled the user receives Nimbus tasks from this service. 💡Note that - even while “Active” the user must be in a User State that Nimbus considers as "Selectable".
  • When disabled, no service calls will be distributed to this user, regardless of their User State.
 
 

Agents/Permissions

Agent Service Settings

🔍Note: This page covers Agent settings of “Skill-based” services. Users in a “MS Teams-based ” service are configured via “Users” tab instead.  

 

PRECONDITIONS

Contact Center licenses are required both on the Service Administration and User Administration. This enables the management of users as “Agents” of one or several services, as well as the related Nimbus Features.

For Tenant Admins: 

  • A “Permissions” tab within the Service Administration allows to assign further Agents or Owners manually. 
  • Also within the Service Administration, User Skills and Levels need to be created first before they can be assigned to Agents in the Portal. 🔎 Refer to our Use Case - Setting up a Contact Center for a full walkthrough.
  • Note that any Team Owners can assign Skills and Responsibilities levels to any Agents you (or other Admins) have assigned. → This is described below on this page.

For Team Owners:

  • Once the Contact Center License is enabled, the “Agents” tab becomes available in Nimbus Portal Service Settings
  • On the “Agents" tab you can manage Skills and Responsibilities of your assigned service-assigned Agents. → See below on this page. 
    💡Note that no Agents will show until a Tenant admin has (manually) assigned users to this service. → See “For Tenant Admins” steps above.
 
A listing of Agents and Owners in a Contact Center Service, allowing to 

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 / Responsibilities)

Allows adjustment of Skills and Responsibilities for each User. 

 

NOTE: EFFECTS OF EDITING AGENT SKILLS AND RESPONSIBILITIES

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 at all.
    • Changes immediately affect all services that the Agent is assigned to (via Nimbus Admin > Service Permissions).
    • Skill and duty changes are made and stored on the user itself. They are als immediately visible to 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:

  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 Learning: When you share Agents between multiple team owners and services, coordinate your changes to their skillsets and responsibilities and agree on common standards in your service Distribution Policies. → Refer to the Distribution Order page for more details and examples.

 
 
 

Interact

Interact Service Settings

💡 Interact allows customers to directly communicate with your service agents via website either via Audio/Video or Instant Messaging (chat), without the need to install or run a any client on their side.

PRECONDITIONS

  • TENANT ADMIN Interact is a feature enabled on tenant level.
  • Enterprise Contact Center An Enterprise or Contact Center license needs to be assigned to a service for the Interact settings to become visible. See Service Administration > General Tab > Licenses.
  • Once configured, Interact allows customers to reach a service directly from external URLs (websites) via small chat or audio/video widgets.
  • 💡Note that the service needs to have a Contact Center license assigned in order to use Instant Messaging with Interact.
 

Editing Interact Service Details

After an Interact license has been assigned to the service, the Interact tab will become visible for further configuration.

An example configuration for a service. Please note that widget key and service ID are unique between services and should not be mixed.

The following options can be configured:

Element

 Description

Active

✅ 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 Instant Message 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 Instant Message Handling.

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

💡 Note that the service needs to have a Contact Center license assigned, Instant Messaging enabled, and an Instant Messaging workflow defined in tab Modalities in order to use Interact with Instant Messaging.

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 the current Service, which later can be inserted into a the web page and used as a contact widget.

Note that "serviceId" and "widgetKey" are unique to the current service and should not be mixed.

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

 
 
 

Companion

Companion Service Settings

Enterprise Routing Contact Center This Tab is only available to Enterprise Routing and Contact Center services. The settings steer general feature availability and visibility to users. More details are described further below on this page.

Companion - Companion features are licensed and enabled per user (General User Settings). More details are described further below on this page.

 

The Companion Service Settings allow you to configure AI-driven features that help improve your overall service performance, for example by assisting your service users with AI-driven context, live captioning, or transcription functions.

Speech Recognizer

☝All Transcription or Live Captioning features described on this page requires prior setup of a Speech Recognizer in the Nimbus Configuration. This is necessary so that the right language engine is used for voice detection. Speech pre-configured Nimbus items that point to a 3rd party service for processing. A configured and working speech recognizer is the prerequisite to using any Companion features that involve voice-to-text capabilities.

Enabling Transcription and Live caption requires a (previously configured) Speech Recognizer to allow live language interactions.

Transcription

INC Transcription Preconditions

PRECONDITIONS

✅Related Admin Use Case: Refer to Use Case - Setting Up Transcription for detailed step-by-step instructions.

Nimbus service and user licensing

🔎Transcription features have service and user requirements. These requirements apply for either mid-session Live Caption or post-session Transcription / Summarization features.

Service requirements

Enterprise Routing Contact Center 

  • Prerequisite: Only Enterprise Routing or Contact Center services have the Companion tab and related Nimbus Features available to the service users.
  • Feature toggle: As Administrator/Team Owner you can enable single Companion features via Companion Service Settings.
  • Data display: To show the transcription data to Nimbus users, you also need to enable the “Companion” widget on the Extension Service Settings. Of course you can also opt to not show the transcription, instead just leveraging the data via the Nimbus Power Automate Connector. → More on this below.

User requirements

Companion 

  • License distribution: Your tenant needs to have sufficient available Companion licenses assigned in Licenses Tenant Settings. You can review and bulk-assign available licenses via License Management.
    💡If no or insufficient licenses are shown, get in touch with a Luware customer success partner to discuss terms and conditions.
  • Enable feature: Every Nimbus user requiring access to features described on this page needs to have a Companion license applied. This can be done by any Administrator in the General User Settings.
    ⮑ Once enabled, the My Sessions page will show a new “Companion” widget with (optionally) enabled features sorted into tabs.
 
 

Azure Speech Services

🔎Features described in the following use “Speech Services” hosted by Microsoft, supporting regions as specified by Microsoft AI services. The usage of the Transcription features and related APIs will cause additional monthly ACS costs outside of your Nimbus subscription.

Speech Services API Setup

 
 

Optional: Power Automate connector integration

🔎Optional step: The Nimbus Power Automate Connector can extract Transcription/Summarization data for implementing additional use cases. To achieve this, the following steps need to be performed by an administrator: 

  • You need to set up a Power Automate flow that uses the “Companion” Trigger Event to react to any ongoing transcription session event.
  • You then require the “Companion” Flow Action to capture the data for any further processing.

💡Some Use Case examples from our Knowledge Base:

 
 
 

INC Azure Billing Transcription

AZURE BILLING

The usage of the Transcription feature will cause additional monthly ACS costs. The costs are determined by Microsoft. Also see https://azure.microsoft.com/en-us/pricing/details/cognitive-services/speech-services/.

  • Before enabling the Transcription feature, get in touch with your Luware Customer Success specialist to discuss terms, usage scenarios and necessary setup procedures.
  • Please note that Nimbus and Transcription support does not cover pricing discussions or make recommendations based on Microsoft Azure infrastructure.
 

When active, the Transcription feature transcribes call contents using Voice-to-Text capabilities. It improves quality assurance and increases the efficiency of call processing, for example making it easier to summarize past customer interactions and possibly transfer them to a CRM system for easier search and later analysis.

Once a call has ended, a Voice Transcription is generated in the background, by leveraging the Nimbus Power Automate Connector > “Companion” Trigger Events and Flow Actions. You can then forward the generated transcription to any target, e.g. by wrapping it into an Adaptive Card as Teams chat message or via Email.

Flow Action for Nimbus Companion

 

Example: Preparing an Transcription Adaptive Card card to send to the user

Optionally you can also show the transcription in My Sessions, allowing users to have a direct written record of previous conversations with customers.

Example of a finalized Transcription on the “My Sessions” page

Summarization

Summarization

INC Public Preview Beta Feature

This feature is in PUBLIC PREVIEW and may not yet be available to all customers. Functionality, scope and design may change considerably.

INC Fair Use Disclaimer

🤝 This feature uses runtime resources under a fair-use policy. Luware may change the usage limit or contact customers that exceed the general usage quota.

✅ PRECONDITIONS

Companion - Summarization is an optional user feature

 

The Nimbus Companion integrates AI summarization as part of a broader suite of Transcription features, aimed at improving service performance and agent efficiency. During a call, Nimbus transcribes the conversation in real time. After the call, the transcript is processed by an AI service to generate a summary with the following aspects

Aspect Description
Title A title generated from Call Direction, Service, and User that accepted the task.
Issue Shortened problem description by the Customer.
Resolution Summary of how the issue was resolved.
Recap A brief paragraph summarizing the interaction.
Narrative Detailed call notes or chat summary of the entire Customer/User Interaction.

Summarization Outputs

Via My Sessions: Summarization outputs can be presented to the agent via My Sessions > Companion widget.
💡All aspects shown within the Companion Widget > Summarization can be hovered over and copied. 
Precondition:  The “Companion” widget itself needs to be enabled in the Extensions Service Settings in order to be shown to users.

Via Nimbus Power Automate Connector: Administrators also have the possibility to flexibly retrieve and store Summarization outputs using Companion Flow Actions and the User/Service SessionID. This can be useful to keep a record of calls, e.g. within a CRM or long-term data storage and evaluation platform.  

Example Summary of a session.

Known Limitations

Summarization relies on the Transcription feature and therefore shares the same design limitations. 

INC Transcription Limitations

KNOWN TRANSCRIPTION LIMITATIONS

💡We are actively working on further improvements to remove or reduce the following limitations:

  • Transcription needs to be enabled in order to use Live Captioning and Summarization. Speech Recognizers are required for all features. 
  • Transcription data is not part of service/user transfers. Data is kept within the current customer/user session.
  • Transcription is currently only supported for inbound calls. Outbound Calls (i.e. Call On Behalf ) will not be transcribed.
 

DESIGN NOTES

  • Feature availability - Transcription relies on external services and APIs. When the feature is disabled or unavailable (e.g. throttling, settings or Microsoft service impediments) info messages are shown in the frontend UI widget. Nimbus task handling and user-customer interactions themselves are not affected by this and will continue normally.
  • Scope limitation: Only the transcription between the Nimbus user and the customer is kept. Third parties and call conference attendees are not part of the content transcribed.
  • Supervision As long as Supervisors remain in Listen or Whisper mode during a conversation, their voice is not being transcribed. Only during ”Barge In" they are part of the conversation and transcription is active.
  • Summarization items generated from the Transcription might be missing when there is not enough data to draw from.
 

Codes Suggestion

INC Public Preview Beta Feature

This feature is in PUBLIC PREVIEW and may not yet be available to all customers. Functionality, scope and design may change considerably.

Precondition: Transcription is required to be enabled and a Transcriber set in order to use Codes Suggestion.

The Codes Suggestion feature provides you suggestions in My Sessions after a call is finished. If you haven't added codes to the session yet, Companion automatically suggests them. In case you have already added your codes, you need to click on the suggest icon to see and apply code suggestions.

AI-suggested Codes in My Sessions, based on what the AI matched with the Transcription

💡When configuring Codes in Configuration, you can add the context related to this code in the Companion Context field to support Nimbus Companion in suggesting codes.

Tags Suggestion

INC Public Preview Beta Feature

This feature is in PUBLIC PREVIEW and may not yet be available to all customers. Functionality, scope and design may change considerably.

Precondition: Transcription is required to be enabled and a Transcriber set in order to use Tags Suggestion.

The Tags Suggestion feature provides you up to 5 tag suggestions in My Sessions from the list of already assigned tags (to service sessions). After a call is finished and you haven't added tags to the session yet, tags suggestions are shown. You can either select specific tags or apply them all. If you have already selected your own tags before, they don't get overwritten – in this case, you need to click on the suggest icon to see and apply tags suggestions.

Example Tag Suggestions in My Sessions

Virtual Assistants

Live Captioning

Precondition: Transcription is required to be enabled in order to use Live Caption.

The Live Caption feature converts ongoing call participant voices directly into text, using Voice-to-Text capabilities. Contents are displayed live on the My Sessions page.

Example of ongoing Live Captioning on the “My Sessions” page

Follow-Up Actions

✅ Service Owner follow-up action: For Transcription and Summarization features to be visible to your users, the “Companion” widget must be enabled via Extensions Service Settings > Widgets. 

You can inform your Service team once the feature has been enabled, so they can pay attention in their My Sessions view accordingly.

 

Power Automate alternative for Companion data: You can also leverage the Nimbus Power Automate Connector by using “Companion” related Trigger Events and Flow Actions, as described in our example Use Case - Analyzing a Transcript. While adding complexity in configuration, the advantage is that you have more fine-tuned control over the transcription data, allowing you to process or store it externally, or opt to showcase it to additional users via the use of Adaptive Cards.

 

Known Limitations

INC Transcription Limitations

KNOWN TRANSCRIPTION LIMITATIONS

💡We are actively working on further improvements to remove or reduce the following limitations:

  • Transcription needs to be enabled in order to use Live Captioning and Summarization. Speech Recognizers are required for all features. 
  • Transcription data is not part of service/user transfers. Data is kept within the current customer/user session.
  • Transcription is currently only supported for inbound calls. Outbound Calls (i.e. Call On Behalf ) will not be transcribed.
 

DESIGN NOTES

  • Feature availability - Transcription relies on external services and APIs. When the feature is disabled or unavailable (e.g. throttling, settings or Microsoft service impediments) info messages are shown in the frontend UI widget. Nimbus task handling and user-customer interactions themselves are not affected by this and will continue normally.
  • Scope limitation: Only the transcription between the Nimbus user and the customer is kept. Third parties and call conference attendees are not part of the content transcribed.
  • Supervision As long as Supervisors remain in Listen or Whisper mode during a conversation, their voice is not being transcribed. Only during ”Barge In" they are part of the conversation and transcription is active.
  • Summarization items generated from the Transcription might be missing when there is not enough data to draw from.
 
 
 

Table of Contents