Triggers

Prev Next

A brief overview of how to build logic into Tulip apps without writing any code.

This topic is featured in the Basic App Design and Logic course in Tulip University.


In this article, you will learn:

  • What types of actions triggers can execute.
  • What types of triggers exist, and how to leverage them.
  • Common use cases for triggers

Triggers allow you to add logic to your app. You can use triggers to interact with devices, send alerts, communicate with backend systems, and more - all without writing a single line of code.

Triggers also allow you to update Variables, a feature for tracking data within an app.

Trigger logic

Triggers use a when, then logic structure:

  • when "event registers in Tulip"
  • then "take action" or "make transition".

Triggers can also contain conditional logic:

  • when "event registers in Tulip"
  • if "condition is met"
  • then "take action"
  • else "take a different action"

Learn more about conditional trigger logic here.

Triggers can be simple like the example below:

ex simple trigger

When a button is pressed, then go to the next Step.

Or, triggers can be more complex, like a barcode scan that queries a backend database to return order information as a variable.

When the barcode scanner outputs at the current Station, then an API Call (run through a Connector Function) retrieves the order details from an external database and stores the value in a Variable. The trigger also then Transitions to the next step.

Types of trigger commands

You can use two types of commands in a trigger:

  1. Action: A change in the app that is not related to changing steps (ex. show an error message, send an email, capture an app screenshot)

  2. Transition: A navigation event in the app itself (ex. go to the next step, complete an app, cancel an app).
    Transitions are can allow other triggers to fire (i.e. start). For example, you can create a app level trigger that fires every time the app is completed.

Types of triggers

There are three types of triggers:

App level triggers

App Level Triggers are activated by these events:

  • App starts
  • App completes
  • App is canceled

They can be modified on the App Tab of the Side Pane:

Learn more about app level triggers here.

Step level triggers

Step level Triggers are activated by these events:

  • At regular time intervals (“time fires”)
  • When there is an input from a machine or device (“machines & devices”)
  • When the Step is opened (“When step opened”)
  • When the Step is closed (“When step closed”)

These can be accessed via the Step Tab in the Side Pane.

Learn more about step level triggers available here

Widget triggers

Widget triggers are activated when a button is pressed.  There can be multiple button Triggers on a Step that are triggered when the respective button is pressed by an operator in the Tulip Player.

These can be accessed in the Widget menu in the Side Pane after selecting a button.

Learn more about widget triggers here.

Examples

Examples of common trigger logic include:

  • Navigate within an app: Use a transition to go to the next or previous step. Or, navigate to a specific step (not in sequential order).

  • Complete an app: to log the metadata of the app.

  • Run a connector function to access a back-end system: Use Connectors to enable Tulip to interact with third-party systems. These connectors can be called from within triggers. This allows you to push or pull data from Tulip into a back-end system using Variables.

  • Sending alerts: Send emails or SMS alerts to a relevant administrator from an app. These messages can include images, status information about the process, or other relevant information.

  • Storing data: Store input data from an app into variables or tables.

  • Use a device to optimize an operator's experience: For operators using both hands during a process, add a trigger to a device event, such as a footpedal, to advance to the next step.

Technical behavior

Table record updates

Tulip bundles sequential update actions to the same table record to be executed in one network request, so they all happen together.

For best performance, we recommend sequencing updates to the same record together – i.e. not breaking up updates to the same record with other table or data actions.

Example 1: Sequential updates to the same record
These actions will all be executed together:
Trigger table write behavior ex1.png

Example 2: Updates to the same record separated by other actions

These actions would not be executed together:

Trigger table write behavior ex2.png

Create a trigger

  1. From the Side Pane, click + in the Triggers section. The trigger editor will open.
  2. Name your trigger to identify what it does in the app. You can also include a description for more details.

Trigger title and description

Further reading