Luware Knowledge

Nimbus Portal Nimbus Admin Nimbus Release Notes Luware Cloud Status
Home Luware Nimbus Usage of Nimbus Configuration Workflows Workflow Activities Queue Activities

Queue Task

Queue Task

Description

Puts a task into the queue for the dedicated service line. The customer will hear wait music. 

🤔 Why pick this over the "Queue" activity?

 

The default "Queue" activity will simply wait until the end criteria is met. “Queue Task” allows for further interactions when paired with "Check Task" and "Cancel Task". 

Learn more…

Depending on your chosen modality you can get a much more sophisticated workflow in place. For example: 

  • Follow up with a “Play Music” activity, which continues to play while performing further steps in the workflow.
  • Keep the customer informed about ongoing connection attempts, e.g. via “Get Queue Position” and specifically catered “Announcement” activites.
  • Use workflow-branching paths, e.g. with with multiple "Check Task" activities – while the original task remains queued.
  • React to long queues with more control – e.g. by only using the "End Task" activity once alternatives have been exhausted, e.g. using “Get Available Users” or “Check Opening Hours” from a backup service before attempting a “Transfer” or deciding to “Cancel Task” and “Disconnect”.
  • Get one of the many Power Automate Use Cases in place to follow-up on specific customers or dropped call scenarios.
 
 

The following user-side actions also end the task:

  • hang up by caller/customer 
  • accepted by Nimbus service user 
 

Usage Conditions: 

  • Can be placed anywhere in the workflow, but requires one preceding “Accept”.
  • Requires one succeeding “Cancel Task” activity to work.
 
Required Predecessor Accept
License
Advanced Routing Enterprise Routing  Contact Center
Modalities Audio / Video Instant Messaging Email External Task

Common Properties

Configurable Properties Description

Distribution Type

Distribution Type1 Description When to pick?

Broadcast

Rings users simultaneously, selected in a batch size of 10 longest-idle users. The first user to pick up the call via Microsoft Teams will handle the task.

💡Does not apply RONA status as it would otherwise flag the entire user batch size.

Achieves a higher visibility, but the ringing call sets 10 selected agents as "Not Available", not allowing further calls to be distributed to them in the meantime. 

👎Makes little sense in high-speed scenarios when the agents are dedicated only to the client to accept calls within a few seconds.

Situationally for very large teams where high-volume call handling is more important than equal work distribution.

Direct

 Will distribute tasks directly to team members, prioritizing the longest idle (active) team member. RONA time is adjustable. No further actions are necessary aside from accepting the call via Microsoft Teams. 

The call with the selected team member is first established via a Teams peer-to-peer call, before it gets escalated to the regular Nimbus conference session.

Useful if you have "Busy on Busy" features enabled for your users. 

👎Otherwise slower than "Direct Conference" and generally not recommended. 

🌟Direct Conference2 

 

 Same distribution as "Direct", but selected team members are directly invited to the Nimbus conference session, allowing them to join much faster and be able to talk to the original caller sooner.

🌟 Our general recommendation for most services. Ensures faster handling of calls without blocking too many users at once for the same ringing call.

✅ While configuring Workflows > “Queue” activities for your Contact Center service, use Direct Conference when you want Nimbus to push tasks automatically, and Pickup3 when agents should self-select tasks from the queue.

 

Pickup3 with Adjustable RONA

 Will show "Pickup" controls in the tasks list of the called team. A call session will be directly established without further intervention, and no further call reporting is possible after this point. A call session that is not accepted (after "Pickup" is clicked) within the given RONA time can be reinserted into the task queue or handled otherwise. In small teams (e.g. volunteers) where it's acceptable to lose a call and reporting data isn't as important. Adds adjustable RONA time to flag users.

Pickup2, 3 Conference1 

 Same as "Pickup with Adjustable RONA", but will directly invite the agent to the Nimbus conference session, allowing them to join much faster and be able to talk to the original caller sooner.

Best performance of all "Pickup" types. Unanswered calls can be re-inserted into the queue and no reporting data1 is lost. 

Suitable for scenarios in which the agents can keep an eye on the Nimbus app or to leave calls sitting in queue to retrieve and handle later.
Table: Available Distribution Types, as configured in your “Queue” activities within your Workflows

🔎Footnotes

1 Workflow differences: Depending on the modality used, certain “Distribution Type” settings may not be supported in your Workflow > Queue Activities.
2 Conference reporting: If a Nimbus task gets aborted (e.g. Hangup by User, Queue left, Max Wait Timeout Reached) Conference invitations get a “Cancelled” result in the Nimbus Reporting Model.
3 Pickup UI behavior: The Pickup button is available for both MS Teams-based and Skill-based routing services, however with behavioral differences.

Learn more…

The main difference is the User Assignment Type behind each service, which steers how Nimbus selects the available users that are currently able (and allowed) to take a task via active “Pickup” button:

  • For MS Teams-based services, every user is part of the same team, and thus equally allowed and capable to “Pickup” the task if his User State allows for it (e.g. not blocked by other tasks). This involves “Pickup” within Adaptive Cards, as a dedicated MS Teams channel is available to the same service users.
  • For Skill-based services, Nimbus needs to check which users are not just capable, but also “allowed" to “Pickup” the task. This is achieved by using Distribution Policies to check for user-matching Skills and Responsibilities at the current distribution level. Additional layers, just as a Preferred/Last User “Initial Preference Phase” also affect which user may pick up the task. As these users are manually added to services – and thus do not share a common MS Teams channel – Adaptive Cards are unsupported in this scenario.
Pickup: Different UI behaviors based on the Service's (User Assignment) Type
 
 
 

 

Conditional Options

(shown based on "Distribution Type")

 Description
Adaptive Cards            
(toggle) 

✅ Requires a "Pickup" Distribution Type to be set.

Enable this for Adaptive Cards to be created automatically within the Service chat channel in MS Teams.

🔍 Adaptive cards will update with the call information. Team members can also opt to pick up calls, listen to voice recordings or mark the call as handled within the card itself.

RONA Timeout

(default / max 00:00:55) 

Specifies the time the system uses to ring a service user, then switches to the next available user in the queue. Applies a RONA status flag when the timeout for the current "Queue" Activity is reached.

💡This setting relies on "Distribution Type" chosen. If not available the RONA timeout is either hard-coded (field greyed-out) or the "Calling / Queue Timeout" settings apply instead. → Also refer to "Distribution Type" above for more info on RONA.

💡RONA status will not apply to "Broadcast" distribution type setting.

 

RING TIME LIMITATION

Microsoft can terminate the dial out in ~35 seconds for some tenants. 

  • For Direct and Pickup with adjustable RONA distributions, we advise you to switch to Direct Conference and Pickup Conference respectively to mitigate the issue.
  • Outbound (scheduled) Call remain at a maximum ringing time of 30 seconds.
 
 
 

Audio / Video

Tip: Workflow Template

Start with our “Queue IVR Voicemail”  Workflow Template to learn how “Queue, Check, Cancel Task”  activities can be used.

A new workflow using the “Queue IVR Voicemail” system template
 
 
 

Instant Messaging

Configurable Properties Description

Distribution Type1

Only “Direct distribution” is available
Adaptive Cards            
(toggle) 		 Not available.

RONA Timeout

(default / max 00:00:55) 

 Specifies the time the system uses to ring a service user, then switches to the next available user in the queue. Applies a RONA status flag when the timeout for the current "Queue" Activity is reached.

1💡Tip: To account for external system access (e.g. Power Automate Connector) consider adding a “Message” activity prior to “Queue Task” to add a bit of delay before distribution . → Also refer to the notes and limitations below.

 

🔎INSTANT MESSAGING DESIGN NOTES

💡The following notes are “by design”. They describe behavior of message protocols which cannot be circumvented or fully mitigated by Nimbus.

☝Data visibility: 

  • Visible Customer Inputs: During an ongoing Instant Messaging session, any messages that customer enters into the chat will be visible to the Nimbus user, including information entered during Workflow Activities such as “Collect Information”.
  • Attachments sent by either customer or user are subject to the Instant Messaging integration vendor (e.g. WhatsApp, Twilio) and their respective data handling and retention policies. If you are uncertain about handling certain media types via Instant Messages, consider restricting the Allowed File Types within your Data Privacy Service Settings.

☝Delay consideration for Power Automate (e.g. preferred user scenarios): 

  • Note that – while Instant Messaging tasks can be routed with minimal delay – the measured roundtrip time of e.g. setting a preferred user via Power Automate Flow Action in many cases lies above 1 second. 
    → When you want to leverage “Preferred User Routing” in your Distribution Policies we recommend to add a delay in your workflow (e.g. via “Message” or “Delay” Conversation Handling Activity) before handing the task over to your “Queue”.

☝Maximum message length is 1600 characters.1

  • Twilio enforces a maximum message length of 1600 characters. Additional Parameters in your (automated) messages count towards this limit.
  • In the UI (e.g.  My Sessions, Nimbus will detect the integration channel (e.g. SMS, RCS, WhatsApp) and display limits and warning messages accordingly.
  • In Workflows, e.g. a “Message” Conversation Handling Activity Nimbus cannot anticipate the incoming integration channel proactively. If the length would be exceeded (e.g. a resolved Parameter leading to a long message), the activity will be skipped.

☝SMS length is impacted by character encoding2. Please keep the length in mind:

  • Please note that when you send a long message (via workflow or Nimbus UI), the customer generally receives multiple SMS at the same time. This could be considered as spam - on top of generating additional cost for the involved actors.
  • The Nimbus UI will show the amount of SMS generated by a chat response. The amount of remaining characters and SMS will be adjusted when you change the encoding (e.g. by using emoticons).

💡Recommendation:  If you intend to handle multiple IM channels via the same workflow and service, keep messages (including resolved Parameters) short in order to not exceed the most restrictive limits. 

1Also refer to Twilio' documentation on maximum message length. 
2Also refer to Twilio's documentation on SMS character limits and instruct your users accordingly before sending out long message chains.

 

KNOWN INSTANT MESSAGING LIMITATIONS

💡The following limitations are currently known to the Nimbus development team. We are actively working on improvements.

General limitations

  • Supervision is currently not supported for Instant Messaging sessions.
  • Instant Messaging modality support for Workflow Activities is currently limited. Workflows with incompatible activities cannot be selected in the service settings.
    • Unsupported workflow activities: If a workflow is edited in post using unsupported Workflow Activities, the Nimbus Reporting session will terminate with a “failed” reporting outcome.

      Show list of supported WF activities

      Currently the following Workflow activities are supported for Instant Messaging workflows:

      ▼Workflow Activity | Chat Integration path via ►

      Interact

      WhatsApp

      SMS

      Conversation Handling

      Accept

      ✅

      ✅

      ✅

      Announcement

      ❌

      ❌

      ❌

      Collect Information

      ✅

      ✅

      ✅

      Delay

      ✅

      ✅

      ✅

      Disconnect

      ✅

      ✅

      ✅

      Disconnect as Handled

      ❌

      ❌

      ❌

      Forward

      ❌

      ❌

      ❌

      Input Customer

      ✅

      ✅

      ✅

      Input Customer (Advanced)

      ❌

      ❌

      ❌

      Mark as Handled

      ❌

      ❌

      ❌

      Message

      ✅

      ✅

      ✅

      Play Music

      ❌

      ❌

      ❌

      Reply

      ❌

      ❌

      ❌

      Save to Parameter

      ✅

      ✅

      ✅

      Standby Duty

      ❌

      ❌

      ❌

      Transfer 

      ✅ (to service only)

      ✅ (to service only)

      ✅ (to service only)

      Virtual User

      ❌

      ❌

      ❌

      Voice Message

      ❌

      ❌

      ❌

      Web Request

      ✅

      ✅

      ✅

      Check

      Availability-based Routing

      ✅

      ✅

      ✅

      Check Opening Hours

      ✅

      ✅

      ✅

      Check Parameter

      ✅

      ✅

      ✅

      Get Available Users

      ✅

      ✅

      ✅

      Get Queue Position

      ✅

      ✅

      ✅

      Wait for Parameter

      ❌

      ❌

      ❌

      Queue

      Cancel Task

      ✅

      ✅

      ✅

      Check Task

      ✅

      ✅

      ✅

      Distribution Priority

      ✅

      ✅

      ✅

      Queue

      ❌

      ❌

      ❌

      Queue Task

      ✅

      ✅

      ✅

      💡General Note: If a workflow is edited in post using unsupported activities, the Nimbus Reporting session will terminate with a “failed” outcome.

       
       
  • Reporting: IM Sessions are currently not differentiated by the Integration method used (either WhatsApp or Interact). 
    → A workaround is to use dedicated IM services for either integration method.
 
 

Interact specific limitations

  • Directly contacting a user via Interact will block a user depending on the incoming modality. The user stays “available” during an Instant Messaging session because a chat is non-blocking, but Audio/Video will result in the user being “not available” because they are in a blocking call.
  • Nimbus Reporting Model - There isn't a service nor user session reported when a user is directly contacted.
 
 

WhatsApp specific limitations

  • Provider Connectors > Twilio - Currently the integration works with “United States” region only.
  • Chat functionality is currently limited to the essential only. 
    • Message editing & deletion, reactions and replies are not supported and will not be supported (Twilio API limitation)
 
 

SMS / RCS specific limitations

SMS/RCS specific limitations

  • Provider Connectors > Twilio - Currently the integration works with “United States” region only.
 
 
 
 
 

Email

Configurable Properties Description

Distribution Type

Only “Direct distribution” is available
Adaptive Cards            
(toggle) 		 Not available.

RONA Timeout

(default / max 00:00:55) 

 Specifies the time the system uses to ring a service user, then switches to the next available user in the queue. Applies a RONA status flag when the timeout for the current "Queue" Activity is reached.
 
 

External Task

Configurable Properties Description

Distribution Type

Only “Direct distribution” is available
Adaptive Cards            
(toggle) 		 Not available.

RONA Timeout

(default / max 00:00:55) 

 Specifies the time the system uses to ring a service user, then switches to the next available user in the queue. Applies a RONA status flag when the timeout for the current "Queue" Activity is reached.
 
 
Queue

Queue Description Puts a task into the queue for the dedicated service line.  The...

Check Task

Check Task Description Checks the current state of the task and takes exit paths ...

Cancel Task

Cancel Task Description Cancels a pending task and all ongoing connection attempt...

Table of Contents