New Studio engine

The original Studio engine has powered billions of flow executions since Studio launched. As Studio usage has grown and customer requirements have become more demanding, Twilio has outgrown it.

The new Studio engine has the following benefits over the classic engine:

• Reliability and resilience: The new Studio engine is designed so that an issue affecting a limited number of executions is contained and cannot cascade to others.
• Scale: The new Studio engine is built to handle certain kinds of high-volume, low-latency workloads that the classic engine was not designed for.
• Future capabilities: The new Studio engine is the foundation for new Studio capabilities that are not possible on the classic engine.

The new Studio engine runs the same Studio API, TwiML, flow definitions, and widgets your flows use today. A small number of edge cases behave differently on the new Studio engine. For the full list, see Behavior differences between engines.

Twilio will migrate your flows to the new Studio engine automatically. You don't need to recreate flows, change any configuration, or take any action in the Studio console.

Your flows will continue to execute normally throughout the migration. The Studio REST API and flow definitions are the same on both engines, and most flows run exactly as they did on the classic engine. The exceptions are listed in Behavior differences between engines.

Twilio migrates accounts in phases. Within each phase, Twilio shifts traffic gradually with automated monitoring and rollback capability throughout.

Before each phase begins, Twilio runs a validation process to confirm that the new Studio engine handles real-world execution patterns the same way as the classic engine, apart from the documented behavior differences. Migration proceeds only once that threshold is met.

The new Studio engine matches the behavior of the classic engine except in the following cases. Each difference affects an edge case, and most flows aren't affected.

When a Liquid expression in a Say/Play widget resolves to null, the two engines produce different TwiML. For example, the following expression resolves to null when foo doesn't exist in the flow context:

{{ foo | to_json }}

The classic engine speaks the word "null" to the caller:

<Say>null</Say>

The new Studio engine renders an empty string, so the caller hears nothing:

<Say></Say>

To play fallback text when a value is missing, use the Liquid default filter, for example {{ foo | default: "your account" }}. For more information, see Liquid template language.

When a caller hangs up at the same moment that a widget transitions, the classic engine can record two final transitions from the same widget in the execution log: one to the next widget and one to the ended state.

The new Studio engine handles one event at a time for each execution. It queues the hangup event and processes it after the pending transitions complete, so the execution log records a single, ordered path to ended.

To view which engine processed an execution, navigate to a flow's execution log in the Studio console and open any execution. The execution details view displays the engine—classic or new Studio engine—that processed it.

If you notice unexpected behavior in a flow execution during or after your migration window, first check whether it matches one of the behavior differences between engines. If it doesn't, contact Twilio Support with the execution SID. Twilio has tooling to identify which engine processed a given execution and can escalate to the engineering team if needed.