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

# Triggers

> Choose, configure, and use the event that starts a workflow.

A trigger defines the event that creates a workflow run. It may listen for an
email, expose an HTTP endpoint, watch a connected service, follow a schedule,
or allow another workflow to call this one.

Every workflow has exactly one trigger.

## Choose the trigger first

You select a trigger when creating a workflow. Choose the event that most
closely represents the boundary of the automation:

| Need                                  | Trigger family                           |
| ------------------------------------- | ---------------------------------------- |
| Receive a request from another system | URL, Webhook, or Form Submission         |
| React to a connected app              | Gmail, Outlook, Google Forms, or TidyCal |
| Run repeatedly                        | Schedule                                 |
| Start from an inbound email address   | Email Hook                               |
| Reuse a workflow from another graph   | Sub-Workflow                             |

The trigger type cannot be swapped in the editor. You can reopen and change its
configuration, but changing the kind of event requires another workflow.

See [Service triggers](/guides/service-triggers) for account-backed events,
[HTTP endpoints and webhooks](/guides/http-webhooks) for inbound requests, and
[Scheduling workflows](/guides/scheduling) for time-based automation.

## Configure the event source

Select the trigger button in the editor header to open its configuration.
Settings vary by trigger and may include:

* a connected account,
* a subject, label, form, or booking filter,
* one or more schedules and timezones, or
* a unique URL to copy into another system.

When you change a configurable trigger, use **Save** to apply it. **Reset**
discards the unsaved fields. Closing a dirty trigger panel also saves the
changes before it closes.

<Warning>
  A broad trigger can create many runs. Configure the narrowest useful account,
  source, and filter before enabling the workflow.
</Warning>

## Use trigger data

New workflows include a **Data from Trigger** node. On the canvas it takes the
name and color of the selected trigger, and its outputs match that trigger's
event payload.

For example:

* an email trigger exposes message and sender fields,
* a URL trigger exposes the method, path, headers, query, and body,
* a schedule exposes its timestamp, and
* a sub-workflow exposes the value passed as **Data In**.

Connect only the outputs the workflow needs. Object and list outputs may let you
select a property or pass the complete value.

The [Triggers reference](/reference/triggers) documents the exact outputs,
filters, request limits, and setup requirements for every trigger.

## Test with the real event

WorkflowDog does not currently provide a generic **Test Run** button. To get
representative trigger data, save the workflow, enable it, and cause the actual
event:

* send the matching email,
* submit the configured form,
* call the endpoint,
* create the booking, or
* wait for the configured schedule.

Then inspect the resulting run and its trigger outputs. Follow
[Testing workflows](/guides/testing-workflows) for the complete loop.

## Trigger configuration and workflow state

Trigger configuration decides which events match. Workflow state decides
whether matching events are accepted as new runs. A correctly configured but
paused workflow will not process new events.

See [Enable and pause](/essentials/enable-and-pause) for lifecycle behavior and
[Workflow runs](/essentials/workflow-runs) for observing what a trigger
created.