Optimising Twilio Flex Licensing with Okta Workflows

Twilio Flex, Twilio’s contact centre solution, supports SAML 2.0 for Agent and Supervisor provisioning and access. Users are provisioned Just In Time into TaskRouter workers with skills and attributes created or updated when a user logs in. Unfortunately Twilio provides no standard way of de-provisioning users. This means that Flex licenses may continue to be consumed by former Agents and Supervisors even if they have left the business. Fortunately Okta Workflows can be used to trigger a call to the Worker API to delete the user automatically when they are unassigned from the application in Okta as shown below. This post will talk you through how to build out this flow, it assumes that you have setup Twilio Flex as outlined in the configuration guide created by Twilio.

How it works

The flow we are creating first queries the TaskRouter Workers API before to retrieve the Worker SID for the de-provisioned user using a Target Worker Expression. It then confirms a worker was returned and calls the API to delete the specific user.

Steps

The first step is to create a new flow, be sure to tick “Save all data that passes through the Flow?” so that we can debug and test. We will trigger the flow with the User Unassigned from Application event. Configure this to point to the Flex Application inside your Okta instance. We then need to build out the Task Router Workspace specific URL and the query string to retrieve our correct user. The two objects we need to build are the Workers URL which is https://taskrouter.twilio.com/v1/Workspaces/<Workspace SID>/Workers and the Target Worker Expression which is of the form TargetWorkersExpression=email=="<email address used in Flex>". In this case the Workspace SID can be obtained in your Twilio Console and the email addressed used in Flex is the Application Alternate ID provided by the User Unassigned from Application Event. These can be created using two Text Concatenate cards as shown below.

Next we will use the API connector GET request card to query the Twilio Workers API to retrieve the Worker SID. If you have not already setup a connector for your Twilio Account you will need to do this now, detailed instructions are available here. To connect to Twilio’s APIs you’ll need to select Basic as the Authentication type and use the Account SID as the Username and Auth Token as the Password in the connection. Once the connection is setup use the URL and Query String we created above as inputs for the request. We then check the body of the returned message to confirm that at least one valid worker has been returned and that we can get a worker SID. This is done by leveraging an Object Get card with the path of workers.0.sid which matches the JSON returned by the Twilio API. We are using a Return Error If card to confirm that we have extracted a SID from the returned data.

Please note that this flow assumes that there is only one user that matches the email address. This should be true but please ensure that you perform testing within your non-production environment to confirm that the expected user is being returned.

Now that we have retrieved the desired users Worker SID we can delete the user by calling the Worker API with the API Connector Delete card and the correct URL which is simply the URL we used before with the Worker SID appended to it. That is it is as follows: https://taskrouter.twilio.com/v1/Workspaces/<Workspace SID>/Workers/<Worker SID>

Testing the flow

You should now have a complete flow ready to test. The simplest way to test is to grab the Okta User ID of a user that has logged into Flex and then run the Test action. This will run the flow and let you know if it is working properly. Next, assuming all went well, log your test user into Flex again to regenerate their user. Then in Okta un-assign the application from them. This should trigger the flow to run which you’ll be able to see in the Flow History and confirm via the Twilio Console.

The Flow File for this example can be found in this GitHub gist.