Twilio Changelog

Push notifications are critical for reaching your end users. But not every message or user event deserves a push.

Starting today, you can intercept any event using Chat’s Pre-Webhooks and choose to suppress the push by returning "mute_notification": "true". Now, system messages or user joined / left events don’t have to show up on the lock screen.

More flexibility and control over how you interact with your customers! Read more in the Chat Webhook documentation

In new TaskRouter projects and Flex projects, TaskRouter workspaces are now always multitasking and TaskRouter no longer supports switching the workspace from multitasking to single-tasking.

Existing projects with single-tasking workspaces are excluded from this change.

To learn more about multi-tasking in TaskRouter, refer to our documentation on multitasking.

Previously, 2FA was implemented at the account-level for the console. This caused owners or admins to inadvertently turn on 2FA for every user with access to their account.

With this change, users can add an extra layer of protection to secure themselves without enforcing 2FA on all other users on an account. You can view the new setting under User Settings in console. When enabled, this setting will take precedence at login.

Owners and admins can still add 2FA as a security requirement for an account through General Settings. When both settings are enabled, we will give precedence to the stronger of the two settings. Moreover, users will never have to do 2FA more than once per login session. For more information, read our 2FA help article.

Previously, when a TaskQueue had been configured for multi-reservation of workers, TaskRouter would try to establish an audio connection for every worker that accepted the reservation request, before rescinding all but one reservation. In rare circumstances, that could lead to more than one worker being placed into conference with the customer.

Now, TaskRouter will only establish the audio connection for the first worker accepting the reservation, while all other worker reservations are immediately rescinded.

To learn more about multi-reservation in TaskRouter, refer to our documentation on multi-reservation in TaskQueues.

Build multi-language flows faster and without duplicating widgets by using Liquid template variables in the Language and Voice fields of Say/Play and Gather widgets.

We are officially ending support for the Epic Conference functionality in Programmable Voice. This was a long-running beta program that allowed developers to create a Voice Conference with up to 1000 participants. It did not prove to be as useful to developers as first envisioned and so we are ending support effective today.

Our standard Programmable Voice Conference provides flexible support for multi-party voice use cases with up to 250 participants. Additional details are available here.

The Twilio Debugger now reports on uncaught exceptions or console.error messages that are triggered from the Flex UI or Flex Plugins. In addition to the Debugger, these notifications can also be consumed via the Debugger Webhooks and Alert Triggers.

You can enable the Debugger Integration on the Pre-Release Features Page in the Flex Admin UI. Learn more about how to use the integration by visiting our End User Guide.

This release of Flex UI introduces minor fixes for chat interaction, a new Action for updating agent activity, and UI performance improvements.

For a full changelog, visit the Flex UI release notes.

You can now record voice calls in Flex with two distinct channels, one per party in the conversation. This allows call center managers and quality supervisors to focus on just the customer or just the agent when analyzing calls. The voice player within Flex Insights will separate both channels and highlight who was talking during the conversation.

Visit our documentation for details on enabling and accessing these recordings.

POST request for Twilio <Pay>, once it has successfully tokenized or created a charge, includes the following updates:

• A new parameter called ProfileId - the identifier of the customer object to which the collected payment method is associated. Depending on your connector, this can be used as a token. This value was previously in the PaymentToken parameter if your <Pay> connector is CardConnect, Stripe, or Chase.
• An updated value in the PaymentToken parameter (depending on your connector) - the tokenized value of the payment method.

These changes provide you context and transparency on the value being returned by your selected <Pay> connector when the payment method is tokenized.

If you are already using <Pay>, these changes will not impact you right away. Learn more about the ProfileId, PaymentToken, and their values by <Pay> Connector here.