> For the complete documentation index, see [llms.txt](https://docs.jetadmin.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.jetadmin.io/workflow/start-a-workflow/choose-a-trigger.md).

# Choose a trigger

In this section you will learn about triggers

A trigger defines when a function runs automatically. In the **Workflows** area, choose **Add Automation** to start with a trigger, or use **Add trigger** for an existing function.

## Function and automation triggers

| Trigger                  | Starts work                         |
| ------------------------ | ----------------------------------- |
| **At regular intervals** | Repeatedly at a configured interval |
| **Based on a schedule**  | According to a configured schedule  |
| **One-time run**         | For a single configured execution   |
| **When record created**  | When a new record is created        |
| **When record updated**  | When a record is updated            |
| **When record deleted**  | When a record is deleted            |

![Add Automation menu with interval, schedule, one-time, and record-event triggers](https://3448227606-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-LQ08RFAKZvFADEiXKFy%2Fuploads%2FUIr7w0IiKd2mpxrnEgpW%2Fworkflow-trigger-menu.jpg?alt=media)

Open Workflows → Add Automation to choose a trigger type.

Follow [Functions and automations](/workflow/functions.md) for screenshots of both menus and the setup sequence. Configure the timing or record source after choosing a type.

## Component actions

An app user can also start a workflow from a button or list action. Open the component's **Actions** configuration and choose **Run Workflow**. Bind the selected record ID or form values as inputs.

See [Run from a button or list action](/workflow/start-a-workflow/run-from-a-button-or-list-action.md). Component success/error callbacks are another entry point; see [Run actions after component success or failure](/workflow/handle-outcomes/component-success-and-failure-actions.md).

## External HTTP events

The separately documented [webhook setup](/workflow/start-a-workflow/receive-an-incoming-webhook.md) covers incoming HTTP events. A webhook option is not shown among the six choices in the supplied Add trigger and Add Automation menus.

## Check the input and result

Identify the values the function needs, inspect the inputs supplied by the trigger, and map the required fields. A record event and an app's selected row may expose different data.

Test both the function and its actual trigger. For update events, check whether the function's writes can cause another event. For deletion events, inspect the payload rather than assuming the deleted record remains queryable.

See [Pass inputs into a workflow](/workflow/build-workflow-steps/pass-inputs-into-a-workflow.md) and [Handle failures and prevent duplicate processing](/workflow/handle-outcomes/handle-failures-and-prevent-duplicate-processing.md).

## Record-event scope

In record-trigger setup, choose the resource and collection. The inspected Jet Tables collection selector explicitly says **collections (changes from Jet only)**. Do not assume that a direct write to an external database will start this automation.

Test creation, updates, and deletion separately using a disposable record changed through Jet. Inspect the event values before mapping them; the available fields and delivery behavior must be verified for your configured trigger.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.jetadmin.io/workflow/start-a-workflow/choose-a-trigger.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.