Announcing important changes to TaskRouter

At Twilio we have spent many months making all our products GDPR compliant, and one of the products at the very heart of many folk’s implementations is TaskRouter. Of course, TaskRouter like all other Twilio products is GDPR compliant, meaning you can build compliant solutions on top of TaskRouter. To achieve this compliance, we have made several changes to TaskRouter functionality and API which are important to be aware of if you are a TaskRouter customer. Here’s everything you need to know about how we retain Personal Identifiable Information (PII) in TaskRouter for the privacy of our users, and how it affects your use of TaskRouter.

TaskRouter Events API

TaskRouter events provide a historical record of everything that happens in a TaskRouter workspace since the start of it. Now, for privacy reasons, any time period (Today – StartDate) that spans greater than 30 days, will have all Personal Identifiable Information (PII) redacted. This includes:

  • task_attributes
  • worker_attributes
  • workspace_name
  • worker_name
  • workflow_name
  • workflow_filter_name
  • workflow_filter_target_name
  • task_queue_name

If your query is less than 30 days, all of this information in the events will remain accessible.

TaskRouter Statistics API

In order to keep the TaskRouter APIs you rely on fast and available, we are making an important change to our Statistics. Currently StartDate + EndDate has no limits to how much data you can pull in one request. Each request will now be limited to a maximum of 31 days. You can still pull as much historical data as you like. To access many months worth of data, you simply make as many requests as needed. If you wish to retain all data for all time however, our recommendation is that you store this yourself in your own data warehouse.

 

These two changes will become effective on July 25th 2018. We know handling changes in API behavior can be difficult, but we hope you agree that the value created here is worth the changes. Please don’t hesitate to reach out with any questions or any concerns.

 

429 Responses

Over the last few weeks, we have continued our rollout of limiting the number of API requests to certain endpoints in the TaskRouter system. If you begin to see a “429 Too many Requests” error, please reach out to us so we can better understand your use case. We anticipate this not to affect the vast majority of our customers.

 

Now let’s dive into what’s new with TaskRouter.

 

Workflow Improvements in Console

We have also made significant improvements on visualizing Workflows in the Console. Rather than describe every change, I encourage you to check out some of your own Workflows to see all of the improvements! This will also allow you to make new ones, and understand some of the default routing behaviors of TaskRouter without having to read through all the docs. We’d love any and all feedback you have on the new experience.

 

New Events

I am happy to announce we’ve added new events which can help you more easily build dynamic UIs or data stores off TaskRouter.

 

Reservation.Completed Event

This event was created to allow differentiation between task completion and reservation completion. This is setting the foundation for upcoming improvements for native transfer support within TaskRouter. For now, we are already exposing the first step of this, reservation.completed, via the Events API and the SDK. If you are building a UI driven by TaskRouter event data, you should use the reservation.completed event to indicate that the agent’s work is done.

 

TaskQueue Events

  • task-queue.created
  • task-queue.deleted
  • task-queue.expression.updated

These will be fired when any TaskQueue is either created, deleted, or its expression updated moving forward. The events will be accessible via the Events API, EventCallBack, but not the SDK initially.

 

These changes set the scene for a lot of new and exciting things we are building with TaskRouter and Flex, we can’t wait to show you more over the coming months.