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:
- Flex Client Library versions
- Feature Releases
- Changes to system configuration and defaults
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.
- Major Releases (1.x.x): Backward incompatible changes to our APIs or dependencies. Major changes to the UI that may influence design customizations.
- Minor Releases (x.1.x): New features, bug fixes, and backwards-compatible dependency updates.
- Patch Releases (x.x.1): Security patches and critical bug fixes.
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:
- Supported: Customer support is provided in accordance with our support plans.
- Maintained: Critical bug and security fixes may be introduced as patch releases.
- Expired: This version is End of Life and is unsupported. We recommend upgrading to a supported version.
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 Expired 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 expires.
When maintenance ends for a major version, all minor versions of that major version will be expired 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 expired 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 expires.
If the next release is a major release (3.0.0), the previous version (2.2.1) will be maintained for another 18 months before the major version and all minor versions expire.
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.
You can still install and use an expired version of Flex UI. When a version of Flex UI expires, support for that version ends. Our support teams will not provide assistance, and the Flex UI may not operate as intended with that version. We will not make any code changes to these versions, including fixing bugs or security issues.
SLAs will not apply if you encounter issues caused by running an expired version of the Flex UI.
Expired versions will be displayed on the Flex Versioning page and can be installed. You can also specify an expired version in Flex UI config. All previous versions are also available via NPM.
Our hosted flex.twilio.com platform allows you to run the Flex UI without needing to build, deploy, and update the app yourself. All of 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. On the Flex Versioning page, you can opt-out and pin your account to a particular minor version. Pinned accounts will continue to update to the latest patch version of that minor release.
We won’t automatically enroll you in a new major release because it may contain breaking changes. You’ll be able to control when to apply that update.
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:
- Available for select customers to opt-in
- Enabled for all new accounts created
- Enabled for all existing accounts
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.
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.