We are always looking to innovate and make our services better, so our APIs and features may change over time.
Changes to Twilio Flex are released in the following ways:
In addition, Twilio Flex relies on many of the underlying products within Twilio's Programmable Communications Cloud. These underlying products allow you to customize Twilio Flex and extend native functionality — and updates to these products may expose additional features you can adopt into your Flex deployment.
The Twilio Flex platform incorporates products and features that are in pilot or beta stages. We release features in these preliminary stages to expose our latest development while we continue to improve edge case handling, scalability, and reliability. Our API SLA and our support plans do not apply to pilot or beta products and features. However, if possible, our customer support team will assist you with questions regarding the way Twilio Flex uses pilot or beta products and features.
In 2019, the Twilio API for WhatsApp and the Twilio Functions & Assets API are in beta. Flex has native support for WhatsApp messages without media, and developers can use the Functions & Assets API to automate the deployment and hosting of their Flex Plugins. Those products are not covered by a Twilio SLA, and questions about the use of their APIs are handled directly by their engineering teams. But Twilio Support will address questions related to the configuration of these products with Flex - for example, updating a WhatsApp number's message handler to route through Flex.
The Twilio Flex client libraries are our primary distribution platform for new changes to Twilio Flex. We use semantic versioning for these releases. All of our available versions and their release candidates are published on NPM.
Minor versions to the Flex UI are released approximately every 3 to 5 weeks. Patch versions are released on an as-needed basis if there are necessary changes that must be introduced before the next scheduled minor release. Major versions are not released on a regular schedule, but we expect they may be released every 8 to 15 months.
Release candidates (x.x.x-rc1) are released on an as-needed basis to enable additional testing before that version's stable release. Release candidates allow you to test new features and APIs as soon as possible; however, those features may change before the stable release. Release candidates should not be used for production use.
The Flex UI release lifecycle has three stages:
Alpha and Beta releases of Flex UI are considered pre-GA, and we exclude these from ongoing support whenever a new version is released. Pre-GA versions move straight from Supported to End-of-life when a new version is released.
We support each major release of the Flex UI until a new major version is available. When a new major version is released, we will maintain the previous major version for at least 12 months before it is end-of-life.
When maintenance ends for a major version, all minor versions of that major version will be end-of-life and no longer supported.
We support the latest minor release version from the most recent major release and actively maintain the previous minor release for an additional 6 months from the latest minor version's release.
When the maintenance period ends for a minor version, it will be end-of-life and no longer supported.
Suppose the latest version is 2.2.1. That version (2.2.x) would be under active maintenance and would receive patch updates. New features and other updates will only be introduced in the next release.
If the next release is a minor release (2.3.0), the previous version (2.2.1) will be maintained for 6 months before that minor version is end-of-life.
If the next release is a major release (3.0.0), the previous version (2.2.1) will be maintained for another 12 months before the major version and all minor versions are end-of-life.
We release patch versions as interim releases between minor versions to resolve issues and accommodate external changes. Patch versions themselves do not have status as an update to a minor version would require a new patch version to be released.
We recommend always using the latest patch version, and to encourage this, we replace the previous patch version with the latest.
When a version of Flex UI is end-of-life (EOL), support for that version ends. You can still install and use an end-of-life version of Flex UI but it may not operate as intended. There won't be any further code changes to end-of-life versions, including bug fixes or security updates. Check the Flex UI minor version End-of-life reference page for EOL dates and guidance on version upgrades.
SLAs will not apply if you encounter issues caused by running an end-of-life version of the Flex UI.
End-of-life versions will be displayed on the Flex Versioning page and can be installed. You can also specify an end-of-life version in Flex UI config. All previous versions are also available via NPM.
Our hosted flex.twilio.com platform allows you to run Flex UI without needing to build, deploy, and update the app yourself. All the minor releases from the current major release are available on the platform, as well as the last minor release of the previous major release.
By default, all accounts are configured to automatically update to new Flex UI minor releases. You can modify how your account is updated using these settings on the Flex Versioning and updates page:
Each version of the Flex UI is a composition of features, APIs, and client SDKs that define the experience of your users. Major features, such as Outbound Dialing and Insights, may have versions or releases of their own. They have a release stage (pilot, beta, GA), and compatibility support for ranges of client library versions.
Many individual features are bundled as part of a new client library version. Larger and more complex features may be released in phases. For example, a new feature within Flex may go through this lifecycle:
When features have a phased rollout, they may be exposed to you as a Feature Toggle. This allows you to opt into features that are not enabled on every account for a particular client library version.
If a feature is displayed in a pilot stage, we're evaluating whether the feature should be further developed into a GA release. These features may not be included in future releases and could be removed without prior announcement.
We intend for all of our Beta and GA features to eventually be included within the Flex UI and enabled for all accounts - i.e., without a Feature Toggle. If a feature is potentially too disruptive to be enabled for everyone, it may stay as a Feature Toggle until the next major release.
Some features within the Flex UI may need to change to provide a better developer experience or meet customer needs. For features within the client libraries, we will mark functions as deprecated. If those features are invoked, they will execute like normal and generate a warning within the JavaScript console. In most situations, a deprecated function will have an alternative that we will direct you to use. These deprecated functions will be identified in our public changelog and release notes and would be removed in the following major release.
Invoking a deprecated feature outside the client libraries, such as within one of Flex's REST APIs, will generate a Warning Debugger Event. These events are available within the Twilio Debugger and the Monitor API.
When Flex is provisioned, we update your account to configure a suite of services - such as TaskRouter, Phone Numbers, and Programmable Chat. As new features are released, these features may require updates to the configuration of other Twilio products. If we identify that these changes can be applied to your account without breaking compatibility, then we will apply the updates as part of the feature release process.
To release Chat Monitoring, a specific type of chat role needs to exist within the Chat Service that Flex leverages. This role wasn't initially provisioned during Flex setup. The addition of this role to existing chat services wouldn't break compatibility, and we applied the new role to existing accounts. Some accounts may have deleted their Chat Service or already added a chat role that would have conflicted with the one needed for monitoring. These accounts were not updated during the release process.
If configuration or system defaults are updated when releasing new features, these will be included alongside the Flex Release Notes. Where possible, the Flex System Checkup will alert you if the configuration of your account has deviated away from what is required to load the Flex UI or execute certain features.