Triggers

Learn how to use triggers to build logic in apps without writing code.

In this article, you will learn:

• Trigger commands, logic, and execution behavior
• Best practices for building and organizing triggers
• Common use cases

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

Common trigger use cases include:

• Navigate within an app: Use a transition to go to a different step.

• Complete an app: 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 and run a connector function via a trigger.

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

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

• Use a device : For operators using both hands during a process, add a trigger for a device event, such as a footpedal, to advance to the next step.

How do triggers work?

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 are bundled by a Trigger Event and consist of Action and conditionals.

Triggers can be simple like the example below:

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

Order of execution

Triggers run in a series and in order based on the Trigger Event (i.e. button click, timer, table row select).

Triggers run sequentially, meaning the first trigger in the series must complete before the second trigger starts executing. This order of trigger execution is known as the trigger queue.

The trigger queue is separate from other tasks within an app, such as operator interactions (i.e. typing into inputs, clicking buttons, or using custom widgets) or custom widget JavaScript.

How are input values used in triggers?

Input values (i.e. variables) are passed by reference to triggers.

Triggers reference the input value of a variable at the time of the trigger execution. If the input value changes before a trigger executes, the trigger will reference the most up-to-date value.

Variables are global to an app, which makes them changeable by other logic in the app.

When do triggers cancel?

Triggers in the trigger queue are canceled, and therefore will not execute, when:

1. A trigger is queued after a transition
   When a Transition is executed (i.e. Next, Complete app, Go to step by name, etc.), any triggers remaining in the queue are canceled.

2. Force closing the Tulip Player
   If an operator force closes the Player (i.e. if an app is unresponsive), any remaining actions in a running trigger and all remaining triggers in the queue are canceled.

Technical behavior

Trigger runtime

• Triggers are executed sequentially in a single trigger runtime. A trigger runtime is the period when a trigger is actively executing in Tulip.
• Triggers never execute in parallel or in the background of other triggers. A new trigger cannot begin executing until the current, running trigger is finished.
• Operators can still interact with the app (e.g. click on buttons, interact with tables) while a trigger is executing. These button clicks and other trigger events will add new triggers to the trigger queue.

Table record updates

Trigger Actions involving Table Records are grouped based on their action type and order. "Store" actions that have the same store location are grouped in one network request. Whereas, actions such as "load record" or "create record" are treated as individual transactions.

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:

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

These actions would not be executed together:

Limits

• Trigger events have a timeout of 100 seconds. Once this time limit is reached, all triggers associated with that event will error and clear from the trigger queue.
• The trigger queue can hold up to 100 events. Once this limit is reached, new trigger events will cancel and not execute.
• The trigger queue will execute up to 100 consecutive transitions, i.e. button trigger transition → loop step open transition → loop step open transition → … Once this limit is reached, new transition triggers will be canceled.

Types of triggers

There are three types of triggers:

App level triggers

You can apply App Level Triggers to the following events:

• App start
• App completed
• App canceled

Access app level triggers from the App Tab.

Learn more about app level triggers here.

Step level triggers

You can apply Step Level Triggers to the following 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 the Step is closed

Access step level triggers from the Step Tab.

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.

Select the desired widget, and then access widget triggers from the Widget Tab.

Learn more about widget triggers here.

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.

Best practices

• Configure triggers to accommodate errors
  Triggers should be configured to proceed or stop in the event of an error. A Trigger can error due to invalid inputs, an execution error, or a failed connector function or table write attempt.
  • When a trigger is configured to proceed, the trigger that errored will stop, but the next trigger will proceed
  • When a trigger is configured to stop, the other triggers in the Trigger Event will be cancelled.

• Avoid having long-running triggers on a step with interactive widgets
  Widgets visually change state immediately upon interaction. While the operator sees the action take place immediately on the widget, the logic may execute with a slight delay because of slow network or a long-running connector.

• Train operators to wait after clicking a transition (e.g. Next Step)
  On a step, triggers queued after a transition will not execute. If an operator engages with a widget that has a transition, they will remain on the step until the transition is executed. For example, if the operator clicks “Next step” and then engages another trigger while waiting, the remaining trigger after the transition will not execute.

• Perform a long-running connector and data updates on separate steps
  Interactions with sensitive data should not be performed on the same step as long-running connector logic. In the event an operator interacts with the step after clicking on a long-running trigger or transition, there is a risk of critical data not being stored.

• Ensure variables have a single input for each step
  Variables should not be shared with competing input logic (i.e. multiple buttons in an app updating the same variable) to avoid race conditions. For example, a trigger capture the current value of a variable. If the value of the variable changes before a trigger captures it, then the data will be incorrect.

Further reading

• List of trigger actions and transitions
• Conditional trigger logic
• Best practices for high performance apps