Workflow triggers

A workflow can be started in three ways. Two of them are configured in the Process section of the workflow settings page, beneath the version card: each has its own row with an on/off toggle, and the two can be enabled independently. The third is configured elsewhere — see From an inbox below.

• Manual — users start the workflow from a matching record in the interface (List View, Summary/Details, or a Workspace). This is the default. See Executing workflows.
• Webhook — external systems start the workflow via an authenticated HTTP POST. Disabled by default.

Webhook triggers are available on all environments, with no production-only restriction.

​

The webhook trigger

When enabled, the webhook lets any external system, an ETL job, a partner service, a CRON in your own infrastructure, start a workflow run on a specific record by calling a stable URL. Two things are separated by design:

• The URL identifies everything fixed about the trigger: which workflow runs, and against which rendering. The only per-call input is the target record.
• The token carries authentication and the identity the run acts as. The run reads and writes data as the token’s user, and the activity log attributes it to that user, so a webhook-triggered run can never do more than that user is allowed to.

For the full HTTP contract, request body, response codes, idempotency, and rate limits, see the Trigger a workflow via webhook API reference.

​

Enabling the webhook

1. Open the workflow settings page and go to the Process section.
2. Toggle Webhook on.

Once enabled:

• the endpoint URL is displayed inline with a copy button;
• a hint shows the JSON body to send, with the target record’s record_id;
• a Generate new URL button lets you rotate the URL (see Regenerating the URL).

Copy the URL and use it from your external system with a valid application token. The workflow starts on the record you pass in the request body.

​

Regenerating the URL

If a URL may have leaked, or you simply want to rotate it, generate a new one from the Generate new URL button below the current URL. When you confirm:

• the URL is updated inline, and the copy button now copies the new one;
• a confirmation toaster briefly appears.

​

Revoking access

You have three independent levers to stop a webhook, without necessarily touching the others: Turning the toggle back on re-enables the same URL and token — it is a pause, not a reset.

​

From an inbox

An inbox backed by a segment can start a workflow by itself, on every record that enters it. Unlike the two above, it is configured on the inbox, not in the workflow’s Process section — the workflow does not know it is being triggered this way.

• It runs as a chosen account, so what the workflow can read and write is bounded by that account’s permissions, like a webhook run.
• It needs Forest Runtime on your infrastructure: Forest never reads your database itself, so something on your side has to watch the segment.
• A record leaves the automation when it leaves the segment. A record whose workflow finished while it is still there is handed to a human in the workflow’s fallback inbox rather than run again.

​

Auditing

Every webhook-triggered run is recorded in the workflow run history and in your Activity Logs, attributed to the token’s user and marked as webhook-triggered so you can distinguish automated runs from manual ones.

​

Learn more