# Triggers

Canonical: https://useformwork.com/docs/workflows/triggers

Choose the event that starts a workflow.

A trigger defines the event that starts a workflow. A workflow can have more than one trigger, and each trigger points to its own first step.

## Form Submitted

Runs when an entry is submitted.

Use it for confirmation email, final documents, fulfilment, and integrations that should receive complete answers.

## Entry Created

Runs when a normal entry is created. This happens before form submission. CSV imports and Create Entry/Row steps do not start this trigger.

Use it to set initial values, create a reference number, or prepare a new record. Keep it lightweight because it runs at the start of the entry lifecycle.

## Answer Updated

Runs when answers are updated. The current editor does not provide a manual field selector. FormWork automatically derives watched field IDs from references in the workflow where possible; an empty/broad watch runs for any changed answer, and reusable-template usage may require that broad watch.

Use it for live calculations, dependent updates, or lookups that must react before submission. Respondent answer changes start it; imports and workflow Create/Update steps do not. Add a Condition if the workflow should apply only in a narrower case.

## Metafield Updated

Runs when internal metafield answers change. Selective metafield filtering is not available in the current editor, so treat it as a broad metafield-change trigger and add a Condition when only some changes should continue.

Use it for approval, assignment, review status, and other admin-operated processes.

## Button Clicked

Runs when a respondent selects a button field in the public form. Configure the trigger with the relevant button field IDs.

Use it for respondent-controlled actions such as **Calculate now**, **Check availability**, or **Verify details**.

## Metafield Button Clicked

Runs when an admin selects a button in the entry's metafields. Configure it with the relevant metafield button IDs.

Use it for operations such as **Approve**, **Reject**, **Send follow-up**, or **Retry fulfilment**.

## API Request Received

Allows the workflow to be started through its workflow API endpoint. The workflow must contain an **API Request Received** trigger; FormWork rejects the request otherwise.

Use it when an external application needs to start a process for an entry. Protect the request with an API key and use the REST API documentation for the endpoint and payload.

## Page Loaded: Current Limitation

**Page Loaded** appears as a trigger type in the workflow editor, but published forms do not currently start it. Do not use it for production workflows until support is available.

For page-specific respondent behavior, use conditional logic and field defaults. For an explicit server action, use a button and the **Button Clicked** trigger.

## Choose a Trigger

| Need | Trigger |
|------|---------|
| Run after final submission | Form Submitted |
| Initialise a new draft or row | Entry Created |
| React to answer changes | Answer Updated |
| React to internal data changes | Metafield Updated |
| Let a respondent start an action | Button Clicked |
| Let an admin start an action | Metafield Button Clicked |
| Let another system start the workflow | API Request Received |

## Avoid Repeated Runs

Workflow updates can themselves match answer or metafield triggers. To keep a process predictable:

- Keep references and conditions focused so automatic answer-field detection can narrow the trigger where possible.
- Add a Condition that checks the previous or current state.
- Avoid writing the same watched value on every run.
- Use a separate status or processed marker when an operation must happen only once.
- Inspect the entry's **Workflow Runs** if a trigger fires more often than expected.