---
title: "Event-Based App Triggers via ‘Virtual’ Tulip Machine"
slug: "event-based-app-triggers-via-tulip-machine"
status: "update"
updated: 2026-08-18T07:33:35Z
published: 2026-08-18T07:33:35Z
canonical: "support.tulip.co/event-based-app-triggers-via-tulip-machine"
---

> ## Documentation Index
> Fetch the complete documentation index at: https://support.tulip.co/llms.txt
> Use this file to discover all available pages before exploring further.

# Event-Based App Triggers via ‘Virtual’ Tulip Machine

*Using a virtual ‘Tulip* Machine*’ to enable event-based* Trigger *logic in an app.*

## Background

Some Tulip customers have legitimate use cases wherein an operator-centric app needs to rapidly react to some context (i.e. some event) outside of: the app or any connected device or Shop Floor machine. In service of such use cases, some customers have developed Tulip apps that use high-frequency (i.e. less than 30 seconds) Timer triggers wherein a timer may be checking for some context (e.g. in a 3rd party system via a Connector Function, or a changed value in a Tulip Table record).

## Problem Statement - High-Frequency Timer Triggers

A high volume of high frequency Timer-based triggers (especially those dependent on response from a 3rd party system or machine) can accumulate in the Trigger Queue faster than they can be executed.

## Solution - Event-Based Triggers via a ‘Virtual’ Tulip Machine

Rather than using high-frequency Timer-based triggers to enable app triggers that respond to events that occur outside of the Tulip app, an alternative (and more reliable and resilient) solution consists of the following:

- A virtual ‘Tulip Machine’ modeled to act as an event stream.
- Machine Attributes mapped to the Tulip API
  - Usage of the Tulip [Machine Monitoring API](/github-testing/docs/use-the-machine-attributes-api) enabling Tulip Apps (or third party systems) to POST “events”.
- [Machine-based triggers](/github-testing/docs/use-machine-outputs-in-triggers) in the relevant Tulip apps to initiate the logic related to the ‘event’.

## High-Level Solution Architecture

Below you will find a high-level diagram of the components involved in implementing such a solution. Following the diagram is an itemized explanation.

![](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/Event Based App Triggers.svg)

1. **“Event”**: This is very much a case-by-case definition. An ‘event’ in this context might be an updated value in a Tulip Table Record, or new content in a third-party system.
2. **Event Source:** The ‘event’ may occur in a Tulip solution (Tulip app, Automation, or Function), or even a third-party system. The remainder of this explanation assumes the event occurs within Tulip. An event outside of Tulip would still use the ‘Machine Attributes API’ and a Service Account with the ‘attributes:report’ scope, but not use a Connector or Connector Function.
3. [**Tulip Machine**](/github-testing/docs/set-up-your-first-machine) **‘Event Stream 1’:** This Tulip Machine acts as a conduit for event signals transmitted as values on the configured Machine Attributes.
4. **Connector: “Event Stream”:** This Connector is configured similar to a Tulip Table API Connector, however note that the Connector Function “Post Machine Attribute” uses the [Machine Monitoring API](/github-testing/docs/use-the-machine-attributes-api) endpoint POST **/attributes/report** which requires a Service Account configured with the ‘**attributes:report**’ scope.
5. **Machines Trigger:** When the ‘Event Source’ POSTs a new ‘event’ via the Machine Monitoring /attributes/report API, a Tulip app can then initiate a [Machines trigger](/github-testing/docs/use-machine-outputs-in-triggers) to perform the necessary logic.

---

Did you find what you were looking for?

You can also head to [community.tulip.co](https://community.tulip.co/?utm_source=intercom&utm_medium=article-link&utm_campaign=all) to post your question or see if others have faced a similar question!

**Machine**

A **Machine** is a digital representation of a physical datasource. Machines have **Attributes** that are updated through an OPC-UA Connector or the Tulip API.

**Trigger**

**Triggers** are groups of logic that are tied to an app event, such as step open, timer, widget interaction, etc. App builders can add triggers to **widgets**, **machines**, **devices**, **apps**, and **steps**.

**Triggers** can contain **actions**, **transitions**, and **conditions**.

**Shop Floor**

The area of the platform responsible for moving applications into production. Under the shop floor, you can manage **Stations**, **Edge Devices,** and the app publication details such as which **Version** is accessible to users, which **Devices** are connected to the app, and which **Interface (display device)** the app is run on.

**Trigger Queue**

All triggers executing in an app are in one sequential single-threaded first-in, first-out queue.

*Example*: All the triggers executed on a button click.

**Machine Attribute**

**Machine Attributes** are setpoints and actual values for different parameters of your **Machine.** Attributes can be mapped to OPC-UA datasource Tags.

**Table Record**

A **Table Record** is a reference to a row in a **Tulip Table**. Table Records can be created either from the Table UI or from with an App Trigger.

To edit a record it must be loaded into a **Table Record Placeholder.**

**Automation**

**Workflow** that performs tasks in the background, without an interface. Automations run logic every time an **event** occurs.

![](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Glossary/Automations1.gif)

**Connectors**

**Connectors** enable real-time connectivity between your Tulip solution and a transactional system (e.g. an ERP). The output of a Connector Function can be used in Tulip Apps, Automations, and Functions.

- **HTTP Connectors** utilize HTTP API endpoints.
- **SQL Connectors** can enable connectivity with certain SQL databases.
- **MQTT Connectors** can connect to MQTT brokers for machine monitoring.

![](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/connector.gif)

**Connector Function**

**Connector Functions** are individual operations to interact with an HTTP or SQL Datasources. Connector Functions can have inputs and outputs, and can be called from: Triggers, Functions, Automations, and AI Agents.

Once pulled, data can be used throughout your applications.

**Tulip Tables**

**Tulip Tables** are a global location to store your production data. **Tables** are made up of **Records** (rows). A single can be accessed from multiple apps or stations at the same time. ![](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/Tulip%20Tables%20Overview%20-%20Feature%20Overview(1).gif)