Studio User Guide

Any builder can use Twilio Studio to quickly create and modify workflows with little to no code. Studio is designed for use by cross-functional teams and individuals who want to build communications tools. It provides a common framework for everyone to collaborate on a project using a single tool. Designers can make swift UX modifications, copywriters can implement their own changes to messaging, and developers can delegate work to others and focus on building more complex features (such as calling Twilio Functions).

Studio provides the following capabilities:

• Trigger Flows by using inbound messages, inbound voice calls, webhooks, or other Studio Flows
• Create, modify, and deploy Flows
• Import and export Flows
• Add and remove Transitions between widgets
• Manage widget settings with the Inspector Panel
• Define Transitions to advance users through Flows
• Create and pass variables
• View Executions (individual runs through Flows)
• Organize use cases and logic in separate Flows
• Use Subflows to break apart large, complex Flows

If you're new to Twilio Studio, see the Getting Started guide to learn the core concepts and interface. After you become familiar with the Studio interface, return to this guide for more detailed information about specific widgets and actions you can perform with Studio.

Studio retains Execution and Step data for 30 days after an Execution starts. (Before October 1, 2021, we retained this data for 30 days after an Execution ended.) After the data expires, it's unavailable through the Studio REST API and Twilio Console.

Studio also deletes active Executions that are still awaiting a response from your end user after 30 days. If your end user responds after their Execution is deleted, they return to the top of the Flow and start another Execution.

Data relating to underlying products used through Studio, such as SMS or Voice call logs, is not automatically deleted at the same time as Execution data. Data generated by other products is retained in line with those products' data policies. Details of individual product data retention policies can be found in the specific product documentation, such as SMS and voice calls.

Studio does not support the PCI Mode setting in Programmable Voice, however you can build PCI compliant Flows that process payments with Studio using the Capture Payments widget.

You can trigger a Flow's start in the following ways:

• Incoming Message
• Incoming Call
• Incoming Conversation
• REST API (Inbound Request)
• Subflow

All five of these appear in the Trigger widget, and you can drag and drop from one or more to reflect your use case.

The Incoming Message trigger is invoked when your Twilio Phone Number (or other message-based channel) receives a new message from the Programmable Messaging API. The API then sends it to your Studio Flow Webhook URL:

https://webhooks.twilio.com/v1/Accounts/{AccountSid}/Flows/{FlowSid}

By connecting Send Message or Send & Wait for Reply widgets, you can respond to those incoming messages and carry on a conversation with the contact.

Studio maintains a unique session based on the Contact's identifier (usually a phone number). For a messaging Flow, Studio only allows a single active Execution per contact. All messages from the contact to that Flow during an active Execution will be handled by that same Execution.

The Incoming Call trigger is invoked when your Twilio Phone Number (or other voice-based channel) receives a new call and sends it to your Studio Flow Webhook URL:

https://webhooks.twilio.com/v1/Accounts/{AccountSid}/Flows/{FlowSid}

By connecting voice widgets, such as Say/Play and Gather Input, you can guide the Contact through a series of interactive voice responses (IVR). You can also connect the contact to another party with Connect Call To or route them to Record Voicemail.

By default, Studio maintains a unique voice session based on the combination of the Contact's identifier (usually a phone number) and the unique Call SID. This ensures every call is handled uniquely, even if concurrent calls use the same Caller ID.

The concurrent calls setting only applies to Executions created via the Incoming Call trigger type. Incoming Message and REST API triggered Executions are not affected.

Note: This functionality changed on October 1, 2018. Flows created after this date handle concurrent calls from the same caller ID by default. For Flows created before that date, make the switch in the call trigger (see screenshot below).

By default, Studio Flows can handle inbound concurrent calls from the same number. The Send and Wait For Reply widget cannot be attached anywhere downstream of the Incoming Call trigger point. If multiple users call from the same number, Studio can't uniquely text back one user in an active execution and correctly identify a reply because callers all share the same number.

For certain specific use cases where callers to a Studio Flow will always have a unique visible caller ID, you can turn off the concurrent calls mode in the Advanced Features dropdown in the Trigger widget (see below). When turned off, you can add the Send and Wait for Reply widget to incoming call trigger connected Flows. This is only recommended for advanced users who know that their Flow is triggered from visible unique caller IDs.