SUPPORT.TWILIO.COM END OF LIFE NOTICE: This site, support.twilio.com, is scheduled to go End of Life on February 27, 2024. All Twilio Support content has been migrated to help.twilio.com, where you can continue to find helpful Support articles, API docs, and Twilio blog content, and escalate your issues to our Support team. We encourage you to update your bookmarks and begin using the new site today for all your Twilio Support needs.

How to Route Flex Consult Invites to Any Queue Without Creating Multiple Workflows

Issue

When building a consult (warm transfer) feature in Flex using the Interactions API’s Invitations (Invites) subresource, developers often want agents to consult any queue dynamically (e.g., “Identity”, “Billing”) without creating a separate workflow for each queue. Common issues include receiving 400 Bad Request errors, not seeing workers reserved on the new consult task, or confusion about how to pass task attributes to the new task.

 

Product

Flex

 

Cause

By default, the Invitations API does not automatically copy attributes from the original task to the new consult task. If the workflow filter logic or task attributes are not set up correctly, the new consult task may not be routed to the intended queue, or no workers may be reserved. Using restrictive filter expressions (such as worker.sid NOT IN task.workerSidsInConversation) without ensuring the attribute is set can also block reservations.

 

Resolution

To implement dynamic consult-to-queue functionality in Flex:

  1. Use the Invitations API to create a consult invite. In your routing object, include:
    • workspace_sid
    • workflow_sid (use a generic consult workflow)
    • attributes (include a custom attribute, e.g., transferQueueName, with the target queue’s name)
  2. In your Flex Workflow, set up filters that match on the custom attribute (e.g., attributes.transferQueueName == "Dept - Setup") and route to the appropriate queue.
  3. When creating the consult, fetch the original task’s attributes, merge only the necessary ones (avoid copying SIDs or system-generated fields), and pass them in the attributes property of the routing object.
  4. Ensure the attribute name and value in your routing object exactly match the workflow filter.
  5. If you use filter expressions like worker.sid NOT IN task.workerSidsInConversation, make sure this attribute is reliably set on the new consult task. Otherwise, remove or adjust the filter to avoid blocking all reservations.

Example routing object:

{
  "properties": {
    "workspace_sid": "WSXXXXXXXXXXXXXXXXXXXXXXX",
    "workflow_sid": "WWXXXXXXXXXXXXXXXXXXXXXX",
    "attributes": {
      "transferQueueName": "Dept - Setup"
      // ...other merged attributes
    }
  }
}

 

Additional Information

  • Only copy attributes that are required for your workflow or business logic. Avoid copying SIDs or system-generated fields from the original task.
  • If no workers are reserved, check that the workflow filter matches the attribute, the queue has available workers, and the task channel is correct.
  • You can use a single workflow with multiple filters for different queues, making your consult logic scalable and maintainable.
  • For more details, see Flex Interactions API documentation.
Have more questions? Submit a request
Powered by Zendesk