# Triggers

> Trigger types, input ownership, and entry-point behavior in Maestro processes.

## What it is

A trigger defines how a process starts. Every process requires at least one trigger, and new processes include a Manual Trigger by default.

## Trigger types

Flow supports the following trigger types:

| Type | Description | Use case |
|---|---|---|
| **Manual Trigger** | Starts the process on demand when you select **Debug** | Testing, debugging, and ad-hoc execution |
| **Scheduled Trigger** | Runs the process on a recurring schedule, defined as an interval or a cron expression | Periodic data syncs, daily reports, recurring cleanup tasks |
| **Connector-based triggers** | Starts the process when an event occurs in an Integration Service connector (for example, new email received or form submitted) | Event-driven automation that reacts to external systems in real time |

## Trigger placement

Triggers are added from the node palette in the bottom toolbar. You can't add a trigger from a node's output handle.

After a trigger is added, it appears on the canvas as a circular node. Its output handle connects to the first node in the process to complete the entry point.

![Node palette open to the Triggers category showing Conversation trigger, Scheduled trigger, and connector-based trigger options including Asana, BambooHR, Box, and others.](https://dev-assets.cms.uipath.com/assets/images/maestro/flow-triggers-3207592f.webp)

:::note
Every trigger must connect to at least one downstream node. Flow displays a warning if a trigger has no outgoing connection.
:::

## Trigger inputs

Input variables are owned by their trigger, not by the process. Each trigger defines its own set of inputs, and those inputs are only populated when that specific trigger fires.

To reference a trigger's input in a downstream node, use the syntax:

```javascript
$vars.<triggerName>.output.<inputName>
```

For example, if a Manual Trigger named `manualTrigger1` defines an input called `userId`:

```javascript
$vars.manualTrigger1.output.userId
```

Trigger inputs are configured from the **Variables** panel. Each input belongs under the trigger that owns it and has its own name and type.

After an input is defined, it appears under that trigger in the **Variables** panel and is accessible downstream as `$vars.<triggerName>.output.<inputName>`.

![Manual Trigger properties panel showing two variables: userId of type string and orderAmount of type number, both accessible via $vars expressions.](https://dev-assets.cms.uipath.com/assets/images/maestro/flow-variables-trigger-f0238c2f.webp)

Refer to [Variables and data flow](variables-and-data-flow.md) for more on expression syntax and how data moves between nodes.

## Multiple triggers

A process can have more than one trigger. Each trigger acts as a separate entry point. When any trigger fires, it starts an independent execution of the process.

This is useful when the same logic needs to run in response to different events. For example, a process might have both a Scheduled Trigger for nightly batch runs and a connector-based trigger that reacts to incoming requests during the day.

Each trigger owns its own inputs. Downstream nodes reference the specific trigger that started the current execution. If your process has a Manual Trigger named `manualTrigger1` and a Scheduled Trigger named `scheduledTrigger1`, each has its own `$vars.<triggerName>.output` namespace.

![Canvas showing a process with two triggers — a Manual Trigger and a Scheduled Trigger — both connected to the same downstream Script node.](https://dev-assets.cms.uipath.com/assets/images/maestro/flow-trigger-manual-scheduled-7f44ec8c.webp)

## Related pages

- **[Variables and data flow](variables-and-data-flow.md)** — expression syntax, node output, trigger input references
- **[The Canvas](canvas-overview.md)** — node palette, properties panel, bottom toolbar
- **[Error handling](flow-error-handling.md)** — handling failures in nodes downstream of a trigger