Multitasking

Task Channels are essentially types of different Tasks such as Voice, Video, etc. When creating a Task, if the Task was originating from a voice call, set "Voice" for the TaskChannel so that TaskRouter can look for Workers that are available to handle "Voice" tasks.

Today we create the following channels by default:

• Voice
• SMS
• Chat
• Video
• Default

You can create Task Channels via the REST API. Note the following limitations on the Task Channel unique name:

• Property identifiers can only be alphanumeric (and _ and $)
• Property identifiers cannot start with a number
• Property identifiers cannot contain variables.
  For example, you can use task_channel.<task_channel_name>_1 or task_channel.<task_channel_name>``$ but task_channel.1<task_channel_name> and task_channel.<task_channel_name> name will result in an error.

TaskRouter cannot assign any Tasks to workers unless a worker is in an available activity and since a worker needs to be able to work on multiple tasks when Multitasking is enabled, it's important to keep the worker Idle. However, TaskRouter will keep track of the available capacity and will not assign more tasks than are allowed for a worker.

This is a perfectly acceptable use case and it will immediately stop TaskRouter from assigning any new Tasks. If a worker wants to temporarily not receive any Tasks, move the worker to an unavailable activity such as "Busy" so that TaskRouter stops assigning Tasks. However, the worker can continue to work on existing Tasks and complete them.

When a worker accepts a reservation and the Task is assigned to the worker, the available capacity for the worker is decremented by 1. Once the existing Task is moved to complete assignment status, TaskRouter automatically increments the available capacity by 1. You can move a Task to complete status by using either the REST API or using the completetask() function in taskrouter JS SDK.

This is currently not supported, but we expect to make it available soon.

You can continue to expose the existing statistics and we will provide more Task Channel specific statistics soon. If you have a request for some specific statistics and metrics please contact support.

If your Twilio project was created prior to December 19, 2019, you may be able to disable/re-enable Multitasking. Multitasking is a workspace level setting, and you can enable/disable by navigating to Workspace/Settings in Console or REST API. Once you enable Multitasking and made all the changes, if for any reason you need to disable Multitasking, simply change it from the Console. All the Capacity you've configured for the workers will remain when you enable Multitasking again.

This section is dedicated to different uses cases and how you can implement them using Multitasking.

At this point based on the worker's availability, configured capacity and type of Task in TaskQueues, TaskRouter will create reservations for appropriate Tasks for each of the workers. If workers are configured to handle Tasks of multiple different types TaskRouter will continue to create reservations for workers for each channel type that is not at maximum capacity, even if they are busy with one channel. For example, if a worker is currently handling a Voice task and a new Chat Task arrives, TaskRouter will create a reservation for the worker if the worker still has available capacity for Chat TaskChannel.

In reality, you may want to block workers from handling any more Tasks if they are busy with Voice Task. To address this use case TaskRouter provides the following pre-defined attributes that you can use to write an appropriate Target Worker Expression in a Workflow.

This attribute returns the current configured capacity of a worker for an appropriate channel. For example, if a worker's Chat capacity is configured to 3 and Voice capacity is configured to 1 then, worker.channel.chat.configured_capacity returns 3 and worker.channel.voice.configured_capacity returns 1.

This attribute returns the total number of tasks that are assigned (only the reservations which are in accepted state) to a specific channel for the worker. For example, if the worker is currently handling 2 Chat Tasks and 0 Voice Tasks then, worker.channel.chat.assigned_tasks returns 2 while worker.channel.voice.assigned_tasks returns 0.

This attribute returns the appropriate channel's current available capacity between 0 and 100 for a worker, where 0 means the worker is capped out handling Tasks for the channel and 100 means the worker is fully available to handle Tasks for the channel. For example, if a worker is configured to handle 1 voice Task and three Chat Tasks and has one Voice reservation state that is pending, accepted, or wrapping, but not assigned to any other Tasks, then worker.channel.voice.available_capacity_percentage returns 0 while worker.channel.chat.available_capacity_percentage returns 100.

To summarize,

worker.channel.chat.available_capacity_percentage = Math.floor((1 - (worker.channel.chat.[reservations]/worker.channel.chat.configured_capacity))\*100 )

Let's review how these attributes can be used to handle the following use cases,

In this scenario, we want to filter out workers from receiving Chat Tasks if they are currently assigned to Voice Task. To do that we will write the following Target Worker Expression,

worker.channel.voice.available_capacity_percentage == 100

Alternatively, we could also write the following expression which does the same thing as the above expression,

worker.channel.voice.assigned_tasks == 0

In this scenario, we want to make workers available to receive Voice Tasks as long as they are handling one or fewer Chat Tasks. To do this we will write the following Target Worker Expression,

worker.channel.chat.assigned_tasks <= 1

This expression will only route Voice Tasks to Workers who are on one or fewer Chat Tasks.

In this scenario, we want to make a worker available to handle SMS Tasks if they are only 50% busy with Chat Task. To do this we will write the following Target Worker Expression,

worker.channel.chat.available_capacity_percentage <= 50

This expression will only route SMS Tasks to Workers who are only 50% busy handling Chat Tasks.

Example: If the worker is configured to handle 4 Chat Tasks and is currently assigned to 2 Chat Tasks, the worker.channel.chat.available_capacity_percentage is 50 and thus makes worker available to receive Tasks from other channels. However, if the worker is configured to handle 3 Chat Tasks is currently assigned to 2Chat Tasks, the worker.channel.chat.available_capacity_percentage is 66 and thus makes worker unavailable to receive Tasks from other channels.

These are just a few use cases that demonstrate how you can use these predefined attributes in your workflow in making appropriate routing decisions for your use case.

You can check out the following FAQ and visit our REST Docs for more information.

One commonly asked use case for TaskRouter is "how do I allow workers to manually pick Tasks from a TaskQueue while also automatically receiving Tasks pushed from TaskRouter". Let's imagine your use case is to route chat tasks to workers. You may want to automatically assign chats to workers, but also expose the full queue in their dashboard and allow them the discretion to manually pull more tasks off the queue. Let's discuss how to do this using Multitasking,

1. Set a Worker Attribute called sid and set its value to the SID of the worker returned by Twilio (this will be automatically available in the future without manually setting).
2. Display all the pending tasks in Chat Queue by using the List Tasks API and filter by Chat Queue and the task assignment status.
3. When a worker selects a Task to work, add two new attributes to the Task. Set manual with the value of 1, and worker_sid to the SID of the worker.
4. Create a workflow that looks like the following,

1
{
2
  "task_routing": {
3
    "filters": [
4
      {
5
        "filter_friendly_name": "Manually grabbed by Workers",
6
        "expression": "manual == 1 AND channel == \"chat\"",
7
        "targets": [
8
          {
9
            "queue": "WQ9e9572cbd73269f7c1f6c99645f14611",
10
            "expression": "task.worker_sid = worker.sid",
11
            "priority": "1000"
12
          }
13
        ]
14
      },
15
      {
16
        "filter_friendly_name": "All other chats",
17
        "expression": "channel == \"chat\"",
18
        "targets": [
19
          {
20
            "queue": "WQ9e9572cbd73269f7c1f6c99645f14611",
21
            "expression": "worker.channel.chat.available_capacity_percentage < 75",
22
            "priority": "50"
23
          }
24
        ]
25
      }
26
    ]
27
  }
28
}
29

Expand image

This workflow assigns a high priority to manually selected tasks and then applies Target Workers Expression to look for worker where the task.worker_sid matches the sid of the worker. Any other task would be added to the queue with lower priority and are routed by TaskRouter based on the worker capacity.

The other piece is to control what capacity your workers have for handling automatically assigned tasks, and to ensure they still have free capacity to handle manually assigned tasks. You'll notice that in this Target Worker Expression TaskRouter onlys creates reservation if the available capacity for the worker is < 75 (percent). This is important to keep some capacity reserved for worker so that they can manually grab Tasks. This is also the place where you can control what percent of Tasks are automatically reserved by TaskRouter Vs what is worker allowed to manually grab. For example, if the total configured capacity for a worker to handle Chat requests is 4 and you want assign up to 3 tasks by TaskRouter but allow worker to grab 1 task manually, then your Target Worker Expression will look like, worker.channel.chat.available_capacity_percentage < 75. However if you want the worker to be able to manually grab up to two tasks, and only be automatically assigned two, then the Target Workers Expression looks like, worker.channel.chat.available_capacity_percentage < 50.