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

    image.png

    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.

    image.png

    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.
    image.png

    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

    image.png

    Further Reading


    Was this article helpful?