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.
Users
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:
GOOD TO KNOW
|
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
How it looks in the UI
On the Services Overview view a user will be shown in state: "(Not) Available" according to the configuration above:
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 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”.
Related Settings to check:
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 |
| Priority |
* see notes below. |
|
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) a "Priority" column indicates how high this task is ranked in the queue. With this setting, tasks may now "displace" existing tasks to a new rank.
Task Priority in "Queue" workflow activites
In a multi-service environment, the "Priority" setting effects your "Distribution Type" setting within a Queue Workflow Activity:
Scenario |
Setup |
Outcome |
|---|---|---|
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 |
|
💡 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 |
|---|---|
| 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 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 status if they ignore a service call or do not answer it within a set period of time seconds.
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:
While in RONA status the user is considered as "Not selectable / Available" by Nimbus and will not receive further call invitations. → Also see User States. |
| RONA Reset Time |
RONA Reset Time (must to be specified)
RONA reset conditionsAn already active RONA state can be reset as follows:
|
GOOD TO KNOW
💡RONA is 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 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 directly affected by the “RONA Timeout (Max. Ring Time)” configured in Workflow Activities, such as Queue, Queue Task and Transfer (to user). For example, a low ring timeout may not give users enough headroom to react to an incoming call before the RONA flag is set.
💡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 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:
|