The trigger nodes that start a workflow, how each trigger owns its inputs, and how a workflow with several triggers behaves.

A trigger defines how a workflow starts. Every workflow requires at least one trigger, and a new workflow includes a Manual Trigger by default. A workflow without a trigger node cannot be debugged: Debug stays unavailable, and the error says that the workflow needs at least one trigger node.

A new workflow starts with a Manual trigger, which starts a run on demand, for example to test the workflow. To start it another way, replace the Manual trigger from the Change trigger list:

Triggers are added with the + button in the bottom toolbar, which opens the Add node panel.

After a trigger is added, it appears on the canvas as a circular node. Its output handle connects to the first node of the workflow, which completes the entry point, the place where a run begins.

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

A node after a trigger references the trigger's input with this syntax:

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

Trigger inputs are called input arguments. They are configured on the Parameters tab of the trigger's properties panel, where Add input argument adds an argument with a name and a type, such as string. The + next to the trigger in the Variables panel opens the Add input variable dialog, which asks for a name, a data type, a description, and a default value. After an argument is defined, it appears under that trigger in the Variables panel and is accessible after the trigger as $vars.<triggerName>.output.<inputName>.

Variables and data flow describes expressions and how data moves between nodes.

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

The same logic can then run in response to different events. For example, a workflow 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. Nodes after a trigger reference the specific trigger that started the current run. If your workflow has a Manual Trigger named manualTrigger1 and a Scheduled Trigger named scheduledTrigger1, each has its own $vars.<triggerName>.output group of values.

The right-click menu of a trigger includes Set as default entry point, which sets that trigger as the default entry point of the workflow.