App Level Triggers
  • 30 Sep 2022
  • 5 Minutes to read
  • Contributors

App Level Triggers

Article summary

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 Context 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.


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

Was this article helpful?