Service Administration

The " Services" view allows administrators to manage, edit and remove existing teams under their tenant. It contains the following elements:

  • A service list with search, filter and create options.
  • A service detail view, opened when clicking on or creating a user. The view is distinguished by several tabs as explained further below.


💡Filtering Tips and Tricks:

A view with filters applied
  • Views with the filter icon allow you narrow down search results. 
  • Note that previous filter settings may still be applied as you revisit a page.
  • Filters are applied on top of your search field text (AND-concatendated).
  • On hierarchical structures such as Organization Units you can hold CTRL while left clicking to single select entries instead of the entire tree.


Overview - Service Listing

The table of existing services lists the following details:

Column Description / Purpose

Clear Name of the Service as originally defined during Service Provisioning.

💡 On MS-Teams based services the name is retrieved from the MS Teams channel name upon Service creation

Organization Unit

All items (including services) in Nimbus are structured into Organization Units (OU). This also determines:

PSTN Number

When previously assigned via General Service Settings > PSTN a number is shown here.

🔍 To assign a PSTN Number, make sure to read the Installation Prerequisites on PSTN / Phone number technical details and limitations. The number can then be assigned via General Service Settings and must be confirmed via Provisioning Script.


The states (from top to bottom) are as follows: 

UNCOMPLETED - Provisioning has started. A new service has been created in Nimbus database, but also needs to registered in Microsoft Azure. 🔍 See Nimbus Installation

SERVICES APPLIED - The provisioning is completed and the service is ready to be called. Nimbus will distribute calls among the service and log them for reporting statistics.

SERVICES RUNNING - A service has been called and calls have been recorded in the Nimbus database.

PSTN APPLIED - A service is now reachable via PSTN. 🔍 Numbers require a phone license to be requested from Microsoft.

PSTN RUNNING - A service has been called via PSTN and calls have been recorded in the Nimbus database.

SUSPENDED - A service user has opted to "remove Nimbus completely" from the services tab. → After 30 days the corresponding Nimbus service will be "pending deletion"

PENDING DELETION - services that have exceeded "suspended" time or have been removed by a tenant administrator will be pending for deletion. Once de-registered from Azure the services will be removed permanently.

Provisioned Since

Date when Service was first provisioned.

🔍 Also see: Nimbus Installation.

User Assignment Type

Shows how (new) users are assigned to this service, as determined during Service Provisioning.

  • MS Teams-based: Directly tied to your MS Teams "Teams" as determined during Service Provisioning. Users get automatically added and synced to a Nimbus service.
  • Skill-based: Manually created service via Service Administration. Requires manual skill-assignment from users you add from within your tenant directory.
  • None: For IVR or first-level redirection services. Has no users, but can be configured by any administrator.

☝ Important to know: The user assignment type is fixated when a service was either provisioned via MS Teams or manually created via Service Administration, e.g. for IVR or skill-based distribution purposes. A switch between MS Teams-based and Skill-based services is not possible due to technical constraints. 

🤔 What does this info entail? The User assignment type determines certain service features and technical details, e.g. syncing users to MS Teams or allowing manual assignment of User Roles and roles.


Shows the Modalities enabled for that service.

🔍 Modalities can be changed via Modality Service Settings of each service. Enabling modalities enables new Nimbus Features.

🔍 Modalities are also enabled per User in the User Administration. A service can only distribute to users the corresponding modality enabled.

💡 Markers will be used throughout the knowledge base to signal or reference a certain modality, e.g. as a prerequirement.


Number of users. This counter depends on the Service type (License) the service was originally provisioned with.

  • For Microsoft Teams-based services, this number corresponds to the team members + owners combined, as retrieved from Microsoft Teams channel.
  • For skill and responsibility-based services, users are manually added to the count via Agent Service Settings.
  • Services with user assignment type "None" do not have users (e.g. first-response IVR services for transfer).

🔍 Also see License Management. The license determines the amount of Nimbus Features accessible to users of that particular service. They are configured in the General "Tab" of each Service's Settings .

 What are the different license types?
 How can I downgrade a license?
Quick Access (Icons)

Provides quick access to specific Service views and options: 

  • Tasks → see Tasks chapter below.
  • Edit Service → See details on Service Settings tabs below or head directly to the Service Settings page for a comprehensive overview of all options.
  • Delete service → See Managing Services chapter below


The task list reflects a live-view of incoming tasks as it is also shown in the live Dashboard of the corresponding Service.
As administrator, you are are authorized to remove ANY task, including such that are still in active conversations →  See note "Task Removal" below.

💡 Since task lists can get very large, make use of the filter by typing into the free search field.

💡 Tasks marked with "Issue" indicator were reported by frontend users of Nimbus, e.g. via the Attendant Console UI.

Current list of tasks.

Removing Tasks / Unblock Calls

You can remove tasks (e.g. to stop blocked calls) from the list clicking the "Delete Task" icon. 


Note that ANY task can be removed from the list - including those that are still running normal. 

  • Check the "State" and "Source" of the call to see if it matches what has been reported to you (e.g. a customer was stuck in "Queue")
  • Use this function only when a task is "stuck" (e.g. due to an erratic call state or system backend malfunction).
  • Please note that task removal will also immediately terminate related call sessions. → Removed tasks are marked as " failed " in the backend, but are not shown in the Service's Reporting and do not negatively impact the Service's KPI.
  • Make sure to inform any involved Nimbus users / service owners before performing this action on a larger scale.

☝ Important: Task removal should be done as an exception to unblock services or users. Please let us know about any ongoing or reoccurring issues that cause "hanging" tasks so the underlying issue can be addressed.


Managing Services

Create a service

Create Service

Outside of Service Provisioning directly via MS Teams, services can also be created via the Administration UI.

IVR Services

IVR services are detached from the usual "Microsoft Teams-based" Nimbus services. Their user assignment is by default set to "None" and special rules apply:

  • Provisioning via Microsoft PowerShell steps are still required after adding the service. Otherwise it is not operable.
  • The service does not relate to any "MS Teams Team" and thus is not assigned to a channel or user list. The main purpose of such a service is call forwarding (e.g. an "IVR Service").
  • "Queue" Activities in Workflows are not allowed as they would would require assigned service users for call distribution. By default, an IVR Workflow Template is provided as a valid example. Workflows with "Queue" steps are omitted from the list.
  • Context and Extensions tabs (usually shown in Service Settings for Nimbus users) are hidden as there is nothing to handle or configure in that aspect.

 💡 All "Administration" user roles have the possibility to access and edit these type of services.

Creation of a new IVR service with no users (team) attached

Skill-based Services

Contact Center Skill-based services require a Contact Center license. Their user assignment is by default "Skill-based" and special rules apply:

💡 All "Administration" user roles and "service owners" have the possibility to access and edit these type of services.

Setting a service to Skill-based User Assignment Type.

🤔 What about Microsoft Teams-based services?
When creating a service via Service Administration, the User Assignment Type “Microsoft Teams-based” is not available as MS Teams-based services are created directly in Teams.
🔍 See Service Provisioning  for more information about MS Teams-based services.

Delete a service

Delete Service

Marking a service for deletion will disable the service. Incoming calls will be answered with a static announcement. 

By clicking the "Delete" icon next to the Service you mark it for "Pending Deletion" in the Administration.

An example service marked for deletion

If you need to undo a pending service selection, please contact your Nimbus support representative. The service will continue existing until the deletion is confirmed via the Provisioning PowerShell script run. Afterwards the application instance of the "marked" service will be permanently removed.


Editing Service Settings

Clicking on any existing service in the list allows you to configure its Service Settings

☝️ Please note:

  • Users with Frontend Portal Roles - primarily Service Members, Agents and Owners) can also access these settings described below. They see the same Service Settings UI as an administrator, yet options are hidden or limited by User Role (RBAC) Matrix restrictions. 
  • Changes to service settings can be applied from either side and any user with the corresponding role. It is highly recommended for administrators to coordinate with team owners when a change of configuration is planned.
  • Certain changes require a run of the PowerShell script. The UI will inform you of pending changes whenever a script run is necessary. More info can be found in the chapter below.

Service Settings




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


  • Settings rely on shared data entities managed via the central Nimbus Configuration. We highly recommend checking there first before adjusting your settings to avoid having go back-and-forth.
  • Settings and options visibility is determined by Organization Units (OU) and the 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.

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 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, IM), such as your configured Workflows for Call Handling, Chat Handling, Email Handling, and External Tasks.

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

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



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 and External Task Handling.
Email - - Learn more by visiting Email and Email Handling.

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!

Enabling and selecting a workflow to handle "External Tasks"

Workflow Changes DURING Service operation hours

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



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

User Assignment Type

Shows how (new) users are assigned to this service. 💡 The default for Nimbus services is “Microsoft Teams Based”, as many users start  Users are directly synched to the Teams channel related to the current service.


🤔 Why is this setting locked for me? During Service Provisioning the User assignment type of a service gets determined. Changing this setting is only is allowed in certain directions, based on which type of service you started with.

Distribution Policy

Contact Center license Nimbus Feature. This is related to Skill-based distribution.


🔎The related Distribution Policies are managed and changed via the Service Administration.

New users immediately active

MS Teams-based Service Types only. 

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.


Toggling yourself “Active” or “Inactive” for different teams via the Nimbus Portal
  • 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 an "Active" state the MS Teams Presence Status also needs to match the criteria of the “Conversations Distribution” section. Otherwise users will not get Nimbus tasks.  
    🔎Also see User States for more details.

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 

Configuring which MS Teams presence is allowed for task distribution to “Active” (on) users.

How it looks in the UI

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

Within Portal > My Services active users can be shown as “Not available” due to their MS Teams presence being set as not allowed for Nimbus Task distribution.


Additional Notes:

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

Aside from MS Teams Presence can block incoming tasks, an example being RONA flags from not responding to an incoming previous task, or the user still being busy in ACW.

💡 MS Teams presence states considered by Nimbus are:

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

When Use Case - Tracking Extended User Presence via Azure Guest Accounts 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”.


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.

INC Distribution Priority

Configurable Property Description Behavior
  • 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 "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.

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

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.

ACW Notes:

  • 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 flag can be enabled and configured to reset itself after a set amount of time, making the user available again.

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)

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

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


Good to know:

💡RONA tasks are returned to Queue: 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 in Broadcast Type Workflow Queues: 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 simultaneously when a call doesn't reach them.

💡RONA is also tracked in the Nimbus Reporting Model, and can be evaluated via Power BI OData interface.


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

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.






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.



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. 

Once Codes 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 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 to have.

💡 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 What can be applied How to Configure
Users (Agents) Direct Call Templates are assigned and triggered by Assistant for an individual user, opened in their system-default browser during an incoming direct call.

Direct Call Templates containing the trigger points and actions and must be defined via Administrator-side Configuration first. Once created, Templates can be added to a user via Assistant User Settings .

🔍 Our Use Case - Chaining of Assistant requests provides a step-by-step example.

Services Service Call Templates are assigned and triggered by Assistant during an incoming service call.

Service Call Templates containing the trigger points and actions must be defined via Administrator-side Configuration first. Once created, Templates can be added to a user via Extension Service Settings.

🔍 Our Use Case - Chaining of Assistant requests provides a step-by-step example.

Conversation Context is opened by Assistant in the Nimbus users default browser during an incoming service call.

Conversation Context items containing the URLs to open must be defined in the Administrator-side Configuration first. Once created, they can be added to a user via Extension Service Settings.

🔍 Our Use Case - Defining and using Conversation Context provides a step-by-step example on how to configure this.

My Sessions

Enterprise Routing Contact Center This Feature requires either an Enterprise Routing or Contact Center license on the service. It allows you to show additional context in the My Sessions view. 

Conversation Context

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.

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

The following points need to be considered for all users before using context in Nimbus:

Consideration Solution / Precondition
Context tabs require your browser to show
✅ During an incoming task Nimbus Portal needs to be open in your browser to open context tabs. Nimbus Portal Links:

INC Nimbus Portal URLs

Switzerland 01
Switzerland 02
Germany 01
Germany 02
United Kingdom 01
Nimbus Portal URLs

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


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

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

Browser popup warning


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

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 not be stored by Nimbus.

As a result:  
⮑ 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 via Nimbus Power Automate Connector) may not resolve or open correctly anymore.

This storage behavior can be changed by enabling the “Store Conversation Context Data”.

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 Historical Sessions). The setting must therefore be enabled by a service owner (Opt-in).  
💡Enabling this setting has no retroactive effect, meaning that only data after enabling this setting will get stored.


🤔What happens when I enable this?

☝ Task information / Session detail data is stored per service session on call termination (transfer by workflow or user).

  • The following is stored per session in both My Sessions and Historical Sessions 
  • On historical (concluded) sessions within My Sessions  
    • ... the "Embedded Context widget" will resolve 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.

☝ Default "My Session Parameters" user data is not stored as it is 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)
Not used

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/killed calls.
  • After 30 days the data is cleared. This also happens when either the service or tenant is being unprovisioned when Uninstalling Nimbus

☝ Best Practice: If you wish to store 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).


🔍 Whitepapers: You can also learn more about the data retention policy in our whitepapers, available in the Documents section.





Widgets extend the My Sessions UI with additional functionality. 💡 Note that certain features are separately licensed and may not show in your UI if preconditions are not met. 

The following widgets can be configured: 

Setting Description
Codes and Tags

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

✅ 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
Contacts (and Search)

INC Feature in phase-out

Features described in the following are in phase-out. Check the related information on alternatives and refer to the Latest Release Notes for upcoming changes.

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

Embedded Context

⮑ Embeds a single website in a My Sessions “Embedded Context” window.

✅ Preconditions:


💡 Please note that only one Context item can be shown embedded per service call.

 🔍 Functionality is the same as described in → chapter Conversation Context above. However, embedding limitations apply (see below).

Example website shown as embedded context in the widget

INC Website Embed 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 * 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:

Live Caption

⮑ Enables Live Caption for calls. If active, Live Caption appears as a widget, transcribing and displaying voice during calls.

✅ Preconditions:

  • Enterprise Routing Contact Center licensed Nimbus Feature. A Transcription License is assigned in General User Settings > Licenses in order to be visible and usable for the user. If no Transcription license is assigned to the user, the error message “Transcription not available. User Transcription License missing.” is shown in the widget.
  • Live Caption must be enabled in the tab Virtual Assistant tab and a Speech Recognizers engine assigned.
Live transcription of an incoming call

Tip: Hiding captioning in the background

Note that Live Caption can only be used with both Live Caption and Transcription enabled in tab Virtual Assistant. However, if you want to hide Transcription from the portal (e.g. if you want to process it only in the background), disabling Live Caption in tab Extensions will prevent transcripts being shown in the widget.


⮑ Enables Voice Transcription for calls. If active, Transcription appears as a widget in My Sessions, showing voice transcripts of call sessions.

✅ Preconditions:

  • Enterprise Routing Contact Center license Nimbus Feature. A Transcription License assigned in General User Settings > Licenses in order to be visible and usable for the user. If no Transcription license is assigned to the user, the error message “Transcription not available. User Transcription License missing.” is shown in the widget.
  • Transcription must be enabled in the tab Virtual Assistant and a Speech Recognizers engine assigned.

Transcription processing in ACW

💡If you have ACW configured in Distribution Service Settings and need it for session closure, you may need to wait for an ongoing saving process of your session's transcription to finish. Once the final transcript is available, it appears in the Transcription widget and you can use it for your ACW.

Session Details

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

✅ Preconditions:


This feature can be used for any service, but the amount of available parameters is extended with higher license tiers. 

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:

Mixture of My Session, System and Custom Parameters


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.


Notes on Parameters in Session Details

  • Any custom/writable parameter information is only updated when previously retrieved from an external directory, e.g. by using the Microsoft Power Automate Connector.
  • Note that your Custom Parameters can also be referenced via Workflows, and update during Trigger Events  depending on the service being called. 
  • Multiple services can make use of the same parameters to standardize the looks of the Session Details 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.

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.

Map Data availability

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.


System Fields and Parameters (CustomerStreetAddress, PostCode, City, State, Country) are used to render the position data on a map. Custom Parameters are not considered nor required.



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 either via Audio/Video or Instant Messaging (chat), without the need to install or run a any client on their side.


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




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


Virtual Assistants

Virtual Assistants Service Settings

INC Beta Feature

This feature is in BETA status. Functionality, design and scope may still change significantly over time.

Virtual Assistants - Transcription Feature

Call transcription and live captioning is now available as a separate feature, enabled via Extension Service Settings and configured via the “Virtual Assistants” tab.

🤔Why should I use this? Transcribing customer calls improves quality assurance and increases the efficiency of call processing, for example making it easier to summarize interactions and possibly transfer them to a CRM system for easier search and later analysis.

License Requirement

Enterprise Contact Center An Enterprise or Contact Center license needs to be assigned to a service for the Virtual Assistants settings to become visible. Transcription is currently in beta and based on Microsoft Cognitive Services in your Microsoft tenant. Supports various regions as specified by Microsoft AI services. Allows to detect and support up to 4 languages per API configuration.

Virtual Assistant works in two modes:

  • Live captioning is performed during the ongoing call and displayed on the My Sessions page.
  • Voice Transcription is triggered when the call ends using Power Automate. You can write the outputs to any target, e.g. into a Teams Message or Mail. 



How to configure

  1. After a Nimbus service is provisioned in your Microsoft Tenant, you can enable the transcription feature by registering the Microsoft Cognitive Services API Key within the Admin portal.
  2. Once configured, you can copy the API Key and register the key in the Virtual Assistants → “Speech Recognizers” Configuration section in the Admin portal.
  3. Afterwards, the speech recognizer needs to be assigned to the new “Virtual Assistants” page of the service, you would like to have transcription enabled.
  • Added new “Virtual Assistants” section to the Administration > Configuration.Allows users to configure the transcription (Speech to Text) feature within Microsoft Cognitive services for services individually
  • Added a new “Virtual Assistants” tab to the Service Settings which uses the previously defined configuration.
  • Added new “Live Caption” and “Transcript” features to the Extension Service Settings tab.
  • Added new Transcription Widget (beta) to the My Sessions view. 
    • When Live Caption is enabled the current conversation is shown in my Sessions. 
    • When Audio Call Transcription is enabled, the historical (concluded) sessions are shown.
  • New “Virtual Assistant” Power Automate action and trigger (to-be-certified connector only).

💡Good to know: 

  • When either feature is not available (e.g. throttling by Microsoft) info messages are shown in the widget.
  • Only the transcription between the current User and the Customer is kept, no third parties.

Transcription In Power Automate

Once a call has ended and we receive the transcription from Microsoft, you can retrieve the transcribed text via Power Automate. We added additional trigger and actions for the Virtual Agent to Power Automate. 

Description This event i triggered, when the virtual user assistant has new update
Method GetOnVirtualUserAssistantUpdate
  • Services
  • Events* (List of Events)
    • Add first event: Voice Transcription Ready
Event Data
  • VirtualUserAssistantEventData
    • ServiceSessionId
    • TenantId
    • ServiceUPN
    • ServiceId
    • ServiceName
    • Event* (Voice Transcription Ready)
Behavior Triggers each time when transcription is stored, right after a user - customer transcription is saved after a finished conversation.
Trigger "When the virtual user assistant has an update"
Method GetOnVirtualUserAssistantUpdate
  • ServiceSessionId
    • Mandatory
  • DataType (single list,. dynamic from Nimbus)
    • Add first type: Transcription
    • Mandatory
  • Return new VirtualUserAssistantData
    • ServiceSessionId
    • TenantId
    • DataType
    • Data*
Behavior Return the complete transcriptioin(s) of the same service session (taskId)
*(of the same ServiceSession)
  • List<Participant>
    • Id
    • Type
      • Customer
      • User
    • Identifier
      • Type
        • PSTN
        • O365Id
        • Upn 
      • Value
  • List<Phrase>
    • Phrase
      • ParticipantId
      • StartedDateTimeUtc
      • Language
        • BCP 47
      • Text
Action "Get Data from Virtual User Assistante"










Applying Setting Changes via PowerShell Script

Certain changes in your settings – e.g. Licensing, Endpoint creation, PSTN number application or change of app privileges – may require changes on your Tenant using your Tenant Admin privileges. Our Microsoft PowerShell script is designed to make Nimbus Service Provisioning and applying follow-up changes on your Tenant as convenient as possible.

🤔 What does the script do? This script is needed to: 

  • Impersonate and enact policies in behalf of your (Tenant) Admin user privileges.
    🔍 See Required App Permissions.
  • Apply changes made on Service Settings that require.
  • Assign available PSTN licenses to services, as well as guide you through any pending settings changes made by other service owners.
    🔍 A detailed script workflow is available on Provisioning via Microsoft PowerShell.

🤔 How can I retrieve the latest script?

The script is updated by Luware on regular basis and will request updates whenever outdated. You can also retrieve it via the download link in the Admin UI:

If you know your data cluster location you can also use the following download URLs:

Table of Contents