--- title: "Transitions" slug: "transitions" updated: 2025-05-21T17:34:20Z published: 2025-05-21T17:34:20Z canonical: "support.tulip.co/transitions" --- > ## Documentation Index > Fetch the complete documentation index at: https://support.tulip.co/llms.txt > Use this file to discover all available pages before exploring further. # Transitions *An explainer on transitions in triggers* Many triggers in Apps will end with a Transition. This article outlines how Transitions operate, the capability of Transitions, and what to expect when running Transitions. WARNING Pre-Transition runtime is being deprecated in LTS 11. Any older apps using this feature must be migrated before LTS14 to continue running. Learn how to migrate apps [here](/r230/docs/a-guide-to-app-transitions#how-to-migrate-from-pretransition-runtime-to-transition-runtime). ## What are Transitions? Transitions are what allows the user to navigate between steps and Apps. Within any kind of trigger, a Transition can be added to appropriately route the user through the Apps you create. ![](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/A%20Guide%20to%20App%20Transitions_206545760.png) By clicking Add new transition, there are a few options: #### Go to Step - Previous - Next - Specific Step - Go To Step By Name #### App - Cancel App - Cancel App Then Log Out Current User - Cancel Then Change To *App* - Cancel Then Change To Step *App, Step* - Complete and Go to Splash Screen - Complete App - Complete App Then Log Out Current User - Complete Then Change To *App* - Complete Then Change To Step *App, Step* - Complete Then Change To Step By Name *Step* - Complete App Then Go To First Step Of App By Name *App* ## Using Transitions Identifying the options available is very important, as only one can be added to a Trigger's Then statement. To clarify this point further, it is possible to add a Transition to each Then in a trigger containing multiple conditions, or else statements. Other notes for Transitions include: - A Transition must go at the end of the Then Actions. This ensures all data is captured, and the Transition is the last action for that Trigger. - If using multiple of the same trigger type (i.e multiple triggers on the same button), it is necessary to ensure all Transition based logic is held within a single trigger. WARNING Running apps with triggers having more than one transition action will no longer be supported starting March 2024 (LTS 12), and affected apps will automatically be archived without the ability to migrate to the new transitions. Starting in R261, you can choose whether to automatically have the affected app utilize a new trigger or follow step-by-step instructions to change the trigger yourself. ### Trigger Interactions with Transitions When a Transition occurs, Step and App Level Triggers may both be activated. For example, a complete trigger on a step may activate a On Step Close, and an On App Complete trigger to fire. The following diagrams outline various examples to display the flow of events with transitions. ![Trigger transition event order diagram](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/Trigger%20transition%20event%20order%20diagram.png) ![How transitions cancel triggers diagram](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/How%20transitions%20cancel%20triggers%20diagram.png) ## How to Migrate from Pre-Transition Runtime to Transition Runtime Apps that are still on the pre-transition runtime will see the following notice: ![Pre%20Transition%20Runtime%20Deprecation%20Notice](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/Pre%20Transition%20Runtime%20Deprecation%20Notice.png) The **Start Migration** will open up a modal with step-by-step instructions on how to migrate their app. This process can be started and stopped at any point. In some cases, apps will be able to migrate automatically and no action is required. All the user must do is click **Convert my app!** ![Pre%20Transition%20Runtime%20Triggers%20Migration%20Process](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/Pre%20Transition%20Runtime%20Triggers%20Migration%20Process.gif) However, in many cases, we will not be able to migrate the app automatically, this means they will need to make changes to their app to migrate. The migration process will provide the following instructions to enable them to migrate their app: ![Manual%20Pre%20Transition%20Runtime%20Trigger%20Migration%201](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/Manual%20Pre%20Transition%20Runtime%20Trigger%20Migration%201.png) ![Manual%20Pre%20Transition%20Runtime%20Trigger%20Migration%202](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/Manual%20Pre%20Transition%20Runtime%20Trigger%20Migration%202.png) ![Manual%20Pre%20Transition%20Runtime%20Trigger%20Migration%203](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/Manual%20Pre%20Transition%20Runtime%20Trigger%20Migration%203.png) ![Manual%20Pre%20Transition%20Runtime%20Trigger%20Migration%204](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/Manual%20Pre%20Transition%20Runtime%20Trigger%20Migration%204.png) ### FAQ **Can the customer rely on it to resolve the issue and not impact the proper functioning of their setup? I.e. will app routing still be possible afterwards?** Yes, for most triggers we can automatically transfer them over and functionality is preserved. For triggers with pre-transition runtime, it will be a manual migration process. **Verbal Walkthrough of Triggers?** When you click on start migration, you can back out and there will be no changes to the app. The start migration button will walk them through and point them to the triggers that need to be changed. It is expected then that they will fix the triggers in their development version of the app. Once they have tested and verified it all works as expected, they will then need to publish the app. They can then run through the **start migration** flow again which will ensure they are ready to convert the app which can't be undone afterward. But they can test their apps without impacting published apps until they do the final conversion (which requires to publish a new version anyway). --- Did you find what you were looking for? You can also head to [community.tulip.co](https://community.tulip.co/?utm_source=intercom&utm_medium=article-link&utm_campaign=all) to post your question or see if others have faced a similar question! **Transitions** **Transitions** are a type of logic in **triggers**. **Transitions** can move operators between steps/apps or start/stop the app.**** Only 1**Transition******can be added to a single **Trigger.** *ex: Complete then change to X app, Next step, Previous step, Cancel app, etc.* **Transitions** **Transitions******are a type of logic in **triggers****.****Transitions** can move operators between steps/apps or start/stop the app. Only 1**Transition******can be added to a single **Trigger.** *ex:**Complete then change to X app, Next step, Previous step, Cancel app, etc.* **Step** A view your users will see within an application. **Steps** can be viewed chronologically or in whatever order best fits your process. Steps can be grouped into **Step Groups**to manage and organize your app Steps. **App Cancel** **App Cancels**are a restart of an application without storing its data in a **Table.** By default, after a cancellation users will be brought back to the **Begin Screen**of your application. This behavior can be adjusted with other **Transition**types. **App Completion** **App Completions**are a mechanism to store immutable data from a Tulip app. When an app is completed, all **Variable's**current values will be stored in the app completions tab.****This completion data can be analyzed in **Analytics.** By default, after a Completion users will be brought back to the **Begin Screen**of your application. This behavior can be adjusted with other **Transition**types. **Trigger** **Triggers** are groups of logic that are tied to an app event, such as step open, timer, widget interaction, etc. App builders can add triggers to **widgets**, **machines**, **devices**, **apps**, and **steps**. **Triggers** can contain **actions**, **transitions**, and **conditions**. **Actions** **Actions**are different operations that can be executed in **Triggers. Actions**cannot move users to other apps, or other**steps.** Many **Actions**can be added to a single **Trigger.** *ex. Store the value of variable x to table field y, Print app step, Adjust Edge device GPIO pin.* **App-Level Triggers** **App-level Triggers**are triggers that are configured with each app. App-level triggers can be triggered based on 3 actions: 1. App Started 2. App Cancelled 3. App Completed