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 |
🤔 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:
GOOD TO KNOW: Active UI toggleAt 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 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.
💡When Emergency Manual Presence Mode is enabled (Admin > Tenant > Extensions > Presence Tracking), these settings continue to apply, but are evaluated against the manually set Nimbus presence state instead of actual Microsoft Teams presence. Manually, only two states are possible — Available and Appear Offline — so tasks are either distributed or they aren't. Of the rows below, only Available and Offline (and "Appear offline") apply; the DND, Busy, and Away rows — including their "optionally configurable" toggles (and the Busy Activities sub-toggles described below) — do not apply, since there is no equivalent manual state to trigger them.
Learn more about Emergency Manual Presence Mode…
🔎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.
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 |
Optionally configurable: Allows Nimbus to distribute tasks to Users even while Busy. 💡 Needs to be on “Distributed to the user” to allow extended Busy activities below to be tracked. |
| Busy Activities: In a Meeting / In a Call | ✅ Requirements:
Optionally configurable, independently of each other:
|
| Away | Optionally configurable: Allows Nimbus to distribute tasks to Users even while Away. |
How it looks in the UI
As an example on the Services Overview a user will be shown in state: "(Not) Ready" according to the configuration above. This User State is a result of:
- The user being “Available" in MS Teams (or, under Emergency Manual Presence Mode, manually set to "Available" in Nimbus).
- 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 their current task, which in turn sets them “Available” for the next Audio/Video task, to be distributed by any other service.
- Aside from MS Teams Presence blocking new tasks, additional Nimbus status flags can also prevent task distribution. Examples are RONA status flagged on the user when not responding to a previously assigned task, or the user still being busy in ACW from the previous task.
✅ Related Workflow-settings to check
Whenever you make adjustments to your Distribution settings we also recommend checking your Workflows – or more specifically Activities such as "Availability-based Routing" or "Queue" – as they will directly affect how Nimbus checks for available users and distributes tasks among them.
Check Activities
Workflows - Check Activities
Used to “check ahead” on the queue, allowing you to reroute a task, change the priority, or just add extra announcements in case the expected waiting time is a bit longer due to all users being unavailable.
|
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, or manually set to "Appear Offline" under Emergency Manual Presence Mode) |
| In Time Available |
Currently active Users are not immediately available when:
|
|
| Direct Available |
Currently at least 1 active user is available and meets all of the following criteria:
|
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
Queue Activities
Workflows - Queue Activities
Used to “steer” how the task is distributed among available Nimbus users. This setting has a direct impact on the Nimbus UI and how many of your users are simultaneously offered a Nimbus task.
|
“Queue” Activities (Queue / Queue Task) |
Distribution Type setting | Task 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 |
Shows conditional “Pickup” buttons, e.g. on My Overview, Services Overview, Live View, Attendant Console). The behavior depends if the service is MS Teams-based or Skill-based:
|
Task Priority
Contact Center Service Type feature. The Task Priority determines how incoming calls from this Service are handled in sequential order.
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” |
|
|
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 (ACW)
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 |
|---|---|
| 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. |
| Allow Call on Behalf during ACW | When enabled, users can start a Call On Behalf during After-Call Work. ACW continues until the outbound call is accepted. |
| ACW for Unsuccessful Outbound |
When enabled, ACW to still be granted to users during the following outcomes:
1 💡Design Note: because of a (potentially very long) MS Teams outbound ring time, ACW will also be granted during dialout and ringing phase. This allows users to leverage ACW early, e.g. for taking notes quickly during high volume outbound call campaign scenarios. |
🔎ACW Design Notes:
- During ACW, Nimbus users are blocked from all other Nimbus Service calls.
- 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.
- 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.
☝Note that ACW will not apply…
- … for Outbound Calls via Workflow, as the destination is first pre-dialed out to, and – once successfully connected – the user needs to accept.
- … for users with Task Parallelization enabled in their General User Settings.
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).
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:
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 be specified)
RONA reset conditionsAn already active RONA state can be reset as follows:
|
💡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.
- 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. With the "Enable Quick Switch Between Tasks" setting turned on, directly activating another task has the same effect — Nimbus parks and resets RONA on the way.
- RONA takes priority in the reported User State: If a user is flagged with RONA on one task while still connected to another, their user state shows RONA rather than Connected — keeping the need for attention visible even while they continue working. → See "Receiving a new task while already connected to a non-blocking task" on the Task Parallelization page.
My Sessions: RONA handled by Indicator
✅Precondition: When a RONA call has been handled by someone other than you:
- Once a missed (RONA) call has been handled by someone else, the task card on My Sessions shows a small green checkbox. Hovering over the checkbox shows the message "Handled".
- GDPR setting: If Show Who Handled a Missed Session is enabled in Data Privacy Service Settings, the message also shows who handled the call (e.g. “Handled by Name Surname”).
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:
💡Note the following limitations:
|