Task Parallelization enables users to handle multiple tasks simultaneously within the Nimbus platform. This includes e.g. managing Audio/Video (AV) calls and External Tasks without blocking the user from receiving a new Audio/Video task. Task Parallelization introduces a more flexible and scalable approach to task handling, especially for service agents working with multiple modalities. Depending on how each modality is configured on the service, users can also receive, pick up and switch to further tasks while a non-blocking non-Audio/Video task is still active – Nimbus parks the previously active task automatically.

✅PRECONDITIONS 

Task Parallelization is enabled on user level via General User Settings (per default disabled). This also allows to set task limits per user, for every supported Nimbus modality. Both general and modality-specific task limits can be set. You may use these limits to account for user experience in handling multiple tasks of certain modality.

💡Good to know: Parking tasks works without having the Task Parallelization feature enabled. Users simply can have only one task parked at a time, as this is their default "maximum".

☝Note that enabling this feature will disable After-Call Work (ACW) for the User. 

• Rule Exception: After-Call Work will still start automatically when an active (non-parked) Audio/Video session ends. This applies to all Audio/Video task types and directions, including consultation calls to services. Parked sessions and other modalities are excluded.

☝Whether an active task blocks the distribution of further tasks is decided per modality on the service, via the "Parallel Tasks Blocking Mode" setting in Modalities Service Settings. Audio/Video tasks always block. → More on this in "(Non-)Blocking Tasks" below.

💡Optional per user: the "Enable Quick Switch Between Tasks" setting in General User Settings (per default disabled, and only available once Task Parallelization is enabled for the user) allows a user to move to another task in a single step, without parking the active one first. → More on this in "Switching between tasks" below.

✅Recommended action

• Changing this setting significantly impacts the user's daily workflow. Changes to the capacity and modalities should be communicated to users and supervisors in advance.
• Review the blocking mode of each modality on your services together with the task limits. Both settings together determine how many tasks actually reach a user while they are working.

 

Key Concepts and Features

Comparison: "Park" and "Hold" 

(Non-)Blocking Tasks

Parked tasks are treated as non-blocking, allowing users to accept new tasks. This is especially useful for handling emergencies or supervisor-assigned tasks without disrupting reporting accuracy.

An active task can be non-blocking as well. For Instant Messaging, Email and External Tasks, the service defines per modality how strictly an active task of that modality holds the user back. The setting is called "Parallel Tasks Blocking Mode" and is found in the corresponding modality tab of the Modalities Service Settings.

The following table shows which states apply for tasks to be considered non-blocking:

💡As long there is another task in a blocking state, the "Unpark" button will be disabled in the UI. Users with the "Enable Quick Switch Between Tasks" setting turned on are the exception – for them the "Unpark" button stays available while another task is active.

Switching between tasks

The "Enable Quick Switch Between Tasks" setting in General User Settings (per default disabled, and only available once Task Parallelization is enabled for the user) lets a user move from one task to another in a single step. Instead of parking the active task and then unparking the next one, the user simply activates/unparks the task they want to work on, and Nimbus reconciles the previously active task automatically:

• Unparking a task — pressing "Unpark" on a parked task parks the currently active task first, then unparks the requested one, effectively swapping the two tasks in a single action. This works for tasks of every modality, Audio/Video included. 
  Keep in mind: A parked Audio task still has to be accepted via the Teams toast; if it is not accepted, both tasks remain parked.
  • Ongoing After-Call Work (ACW) is ended first – If the user is in ACW for a task and provided that this ACW may be ended, either because the service allows ending it early or because it has already been extended. Ending ACW this way does not trigger a new task to be assigned as a side effect; the user continues directly with the task they activated.
• Starting a Call on Behalf — starting a Call on Behalf parks the currently active task first, regardless of its modality (Audio/Video included). The Call on Behalf button is available on every relevant UI (Assistant, My Overview, Services Overview, Attendant Console, and My Sessions) whenever a task is active. If the user has already reached their Audio/Video task limit, the action is blocked and a tooltip explains why. If parking the active task fails for any reason, the Call on Behalf is not started either.
• Activating a task still clears a RONA flag, consistent with existing behavior, also when the switch parks another task on the way.
• If the newly activated task is a blocking one (any Audio/Video task, or a modality configured as "Blocking"), Nimbus stops distributing further tasks to the user from that moment on.

☝Starting a Call on Behalf while a task is active

With "Enable Quick Switch Between Tasks" turned on, users also start a "Call on Behalf" without parking their current task first. The action stays available in Assistant, My Overview, the Services Overview, Attendant Console and My Sessions while a task is active:

• The active task is parked automatically when the call is started from the "Call on Behalf" dialog, regardless of its modality — including an active Audio/Video task. This overrides the usual rule that an active Audio/Video task blocks starting new actions.
• Task limits still apply. The user needs a free Audio/Video task slot for the call. If the Audio/Video limit has already been reached, the start button in the dialog is disabled and a tooltip points out that the maximum number of Audio/Video tasks is already reached.
• If the active task cannot be parked, the call is not started either. Nimbus informs the user on the UI and leaves the active task untouched.

Receiving a new task while already connected to a non-blocking task

When the task a user is currently connected to is configured as "Non-blocking" or "Blocking except for Audio/Video tasks", Nimbus can distribute a new task to that user exactly as if they were fully available – as long as they still have free capacity, both overall and for the modality of the new task.

• The incoming task is shown above the connected one on My Sessions and Attendant Console, with an orange outline on the Active widget whenever a user has both a Connected and an Incoming session at the same time.
• Accepting the incoming task automatically parks the connected non-blocking task. If the user had unsent changes on the connected task (e.g. an email reply or an unsent Instant Messaging draft), that draft is saved automatically before parking.
• Declining or ignoring the incoming invitation does not change the state of the ongoing connected task. If Persistent RONA is configured for the service, the user is still flagged with RONA as usual. Parking the still-connected task afterwards does not clear that RONA flag; unparking a parked task still resets RONA, exactly as it does today.

User availability is calculated based on whether a user can still receive a task, not simply on whether they are already working on one: a user is Available if they can still take on at least one more task, and Not Available once they have reached their total or per-modality task limit, or their active task is a blocking one. The Time in State field continues to be tracked the same way regardless of which of these reasons applies. Availability calculation on the service level is unaffected – it already reflects users correctly as available whenever they can take on a non-blocking task without exceeding their limit.

Because of this, a user who is already connected to a non-blocking task can receive a new task before a fully idle colleague does, depending on the configured Distribution Policy (e.g. Longest-Idle):

• 12:00 – User A accepts a non-blocking task and becomes selectable again, since the task doesn't block.
• 12:01 – User B ends an Audio/Video call and becomes idle.
• 12:02 – A new Audio/Video task enters the queue. User A, still the longest-idle user, receives the invitation ahead of User B.

User state conflicts are resolved as follows:

• If a user is in persistentRONAwhile still connected to another task, the user state shows RONA, since it takes priority – this keeps the need for attention visible even though the user is actively working. Example: a user connected to an urgent Email session ignores an incoming Audio/Video call and is shown as RONA while still working the Email.
• If a user is being invited to a new task while already connected to another, the user state shows Connected until the invitation is answered, rather than Ringing. Example: a user connected to an Instant Messaging task receives an incoming Audio/Video invitation; the state remains Connected until they answer it.

Picking up a task while working on another task

Users can also "Pick up" a waiting task from a queue while they are already working on an active task. Nimbus parks the active task automatically as soon as the picked-up task is accepted. The usual conditions still apply:

• The active task must be non-blocking. Pickup is not offered while an Audio/Video task is active, or while an active task belongs to a modality that the service configured as "Blocking".
• Capacity and responsibility apply as always. The user needs a free task slot – both overall and for the modality of the task – and has to be responsible for the service the task waits in. → See Task Queue and Distribution.

🔎 See also "Receiving a new task while already connected to a non-blocking task" above for how a task can also be pushed to a user in this situation, rather than picked up by them.

RONA and other User State flags

Same as single tasks, parallel tasks will cause users to be passively flagged with a persistent RONA state, regardless if there is a parked session or not.
🔎These flags also are part of User States that prevent further tasks to be distributed in parallel.

☝This also applies while the user is working: if a task is distributed to a user who is already handling another task and the user ignores it, they are flagged with persistentRONA and receive no further tasks until the flag is cleared – even if their task limits would still allow more tasks. See "Receiving a new task while already connected to a non-blocking task" above for how this interacts with the Connected state.

💡Users can reset their RONA state by unparking a task.

Task distribution among multiple users with "parked" tasks

🔎 Nimbus uses a Task Queue and Distribution system that defaults into distributing tasks to the "Longest-Idle" user. A user with a a parked task is still considered "selectable" and thus available to take new tasks.

💡In this example we focus on just two Users A and B, using Audio Calls as modality. A maximum task limit of 2 is set for simplicity:

Data Visibility

Nimbus UI

The Nimbus UI will show notable differences to users. With task parallelization enabled on their settings, users will now see a capacity indicator in the header of My Overview, My Sessions, Attendant Console, and Assistant. The header conveys capacity information in number and color, showing both used and available task slots per modality.

☝️Task capacity visibility

• Regular users (Team Members, Agents) may only see their own task capacity as a numerical value. Other capacity is just shown as a visual representation (e.g. bar-chart). 
• By accessing Personal Dashboards users in a "User Supervisor" Portal Role can see the capacity of all other users. To do so, they need to add a "Modalities and Capacity" column to the "User State" or "User Supervisor" widget.

 

Handling tasks in Nimbus Assistant, My Sessions and Attendant Console

Assistant shows incoming tasks of all modalities while another task is already connected. For Instant Messaging, External Tasks and Email, users handle the incoming task directly from Assistant, with the same options they have in Attendant Console and My Sessions:

• Accept the task and start working on it. The connected task is parked automatically.
• Park it right away to keep the task without interrupting the one they are working on. This direct-park option is offered for non-Audio/Video tasks only: since a customer is already waiting live on an Audio/Video call, Nimbus expects the user to at least briefly connect and greet them before parking, rather than parking the call before any interaction takes place. This exception does not apply to the Adaptive Card used for Interact.
• Decline the task so that it returns to the workflow.

While a task is connected, the "Parked Tasks" section is not shown in Assistant – the connected task and any incoming task take its place.

Reporting

While definitely affecting KPIs Task Parallelization has no specific or systemic reflection on Nimbus Reporting. Nimbus will always create and track separate Service / User sessions for each task, of course with an overlap of session timestamps to be expected.

Known Limitations