> For the complete documentation index, see [llms.txt](https://docs.rewst.help/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.rewst.help/rewst-documentation/documentation/automations/nodes/nodes-triggers.md). # Nodes: Triggers {% hint style="info" %} Ask the Rewst Agent to explain any node in Rewst. This documentation exists to help you get started, but in-platform questions and learning are the fastest way to achieve automation. {% endhint %} ## What is a trigger? *Triggers* initiate workflows in Rewst. Every workflow must have at least one trigger node to define when and how it starts. Essentially, triggers put the automate in automation. Choosing the right trigger ensures that your workflows execute at the right time, with the right data, to drive efficiency and consistency in your operations. The trigger you pick decides what kicks the workflow off: a person, a schedule, an inbound webhook, or a submitted form. ## View all triggers
Navigate to **Automations > Triggers** in the left side menu of Rewst to view the total triggers page, which contains a sortable list of all triggers in your Rewst instance, organized by tabs labeled with automation type. Toggle any trigger to enabled or disabled in the **Enabled** column. Once toggled on, the slider will turn blue. ## Create a trigger Click on any trigger in the list under the **Triggers** tab. Drag it and drop it onto the Workflow Builder Canvas. Then, click on the placed trigger to open its configuration settings.
## Trigger types: Built-in triggers {% hint style="info" %} These are the triggers that are automatically included in Rewst regardless of any integrations you may have set up in your instance. Click on any of the trigger types below to expand and read its documentation. {% endhint %}
Receive Form This trigger starts the workflow when someone submits a form. The submitted field values arrive as the workflow's input. The recommended way to wire this is to bind a published form to the workflow rather than hand-authoring the trigger's inputs. Binding keeps the form's submitted fields in sync with what the workflow expects. Toggle the trigger to **Enabled** or **Disabled** as desired.
Request Options This is a specialized trigger used to supply dynamic choices to a form field. When a form needs its drop-down options generated by a workflow, for example "list this customer' mailboxes", that options workflow starts with this trigger. The workflow behind an options trigger typically ends by producing an array of `{ value, label }` options that the form field then displays.
* A form field's options source is "Static options" or "Workflow options". A workflow options source needs a separate workflow that starts with Request Options. * The Request Options output can take two forms. Either: * Write a final `{value, label}` array to `CTX.options`, * Return raw records and map value and label in the form field's settings
Run on Schedule This trigger starts the workflow on a schedule, at a recurring interval or specific times. Use this for anything that should run on a clock: nightly syncs, hourly polls, weekly reports. For a one-off pause inside a running workflow, use the Delay node instead; for waiting on an external callback, use Wait for Webhook.
Receive Webhook *Webhook triggers* are an effective way to kick off a workflow with context from external systems. By sending an API request to a webhook trigger, Rewst will fire the workflow and include any data and or queries included in the request. For example, when a customer submits a support ticket, a webhook instantly sends that information to Rewst and starts a workflow. This trigger starts the workflow when an inbound HTTP webhook arrives at the workflow's webhook URL. The request body and metadata become the workflow's input. The body, headers, and query items show up as `TRIGGER.webhook` , not "inputs". Use this when an outside system needs to notify Rewst that something happened, such as when a ticket was created, an alert fired, etc. For starting a workflow on a clock, use the Run on Schedule trigger instead.
Start Manually This trigger starts the workflow on demand. A person runs it from the UI, or another system starts it with run input. Preview and live runs can pass values in under `INPUT.*`.
Workflow Completed This trigger allows you to run the workflow you're currently building in your Workflow Builder Canvas after another workflow completes. For previous users of Rewst Classic, this is how Rewst now implements completion handlers. Settings allow for the trigger to fire if the previous workflow is completed, failed, canceled, or timed out.
## Trigger types: Integration-specific triggers Rewst offers additional triggers for some of our integrations tailored to different automation needs. Explore the available triggers in the trigger type list to find the best fit for your specific processes. Try asking the Rewst Agent what each integration-specific trigger does to learn more about how it can be used, or read more about included triggers on each integration's info page in this site. {% hint style="info" %} For users of Rewst Classic: \ We're still migrating many of our integration triggers into new Rewst. Our PSA ticket triggers will all be available at the time of Rewst's general release, but other integration triggers are still being released on a scheduled basis. If you require a specific integration trigger, reach out and request that it become a priority via our Canny. {% endhint %} --- # 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 dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.rewst.help/rewst-documentation/documentation/automations/nodes/nodes-triggers.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. 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.