App Level Triggers
- 30 Sep 2022
- 4 Minutes to read
- Contributors
- Print
App Level Triggers
- Updated on 30 Sep 2022
- 4 Minutes to read
- Contributors
- Print
Article summary
Did you find this summary helpful?
Thank you for your feedback
In this article, you will learn:
- What are App level Triggers?
- Types of App level Triggers
- Example App level Triggers usecases
App Triggers
App Level Triggers are activated by these events.
- App started.
- App completes
- App is cancelled
They can be modified on the App Tab of the Side Pane:
All of these Triggers can be activated automatically on any Step.
For example, if you have a "Complete" button on three different steps, the "App Completed" trigger can run on any of those steps.
Note
Transitions cannot be added to App Level Triggers
App Started
The app started App Level Triggers will run everytime an app is started within the Tulip Player. One application can launch another app to any Step, but App Started triggers will run regardless of the Step where the app is started.
Example Usecase
App Started Triggers are very useful for loading any assets required throughout your application.
ex. My application relies on a Station Handoff table where the current status of each Station is stored, this table includes the throughput of my station, its physical location, and more. Each Record in my Table is associated with a station name.
App Completed
App completed, much like Step level Triggers for "on step exit", will run whenever an app completion is executed.
Example Usecase
"App Completed" Triggers are very useful to close out processes.
ex. When my users complete the fulfilment application, I want to send an email to purchasing to reorder the materials I requested.
App Cancelled
App cancelled Triggers will fire when an app Transition is fired that cancels the app.
Example Usecase
App Cancelled Triggers are very useful when supporting user mistakes within an application. When a mistake is made, a Transition can be triggered to cancel the application, this will remove any app completions with that erronious data. Custom behavior might be required in this case, and that is where App Cancelled Triggers come into play.
ex. When a defect is created for a mixing process, users are walked through a process to try to resolve that defect. When this app is complete, that batch is assumed to be defective, but if the batch can be resolved, an app cancel is executed so the batch doesn't count towards defect counts. If this is the case, we want to write what step of troubleshooting resolved the defect to a Table, so we can better understand the most common failure modes
Further Reading
.gif)
Was this article helpful?
