> For the complete documentation index, see [llms.txt](https://docs.distro.so/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.distro.so/workflows/triggers.md).

# Workflow triggers

The trigger decides what starts a workflow and what data later steps can use. Choose the trigger that matches the source of the lead or event.

## Available triggers

| Trigger                                 | Use it when…                                                                     | Setup to review                                                                        |
| --------------------------------------- | -------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------- |
| **New form submission**                 | A prospect completes a Distro form or a connected external form.                 | Saved questions, field mapping, response mode, and the form's active workflow version. |
| **Browser extension**                   | A member starts the flow from the Distro extension.                              | Input fields, prefill mappings, workspace access, and extension availability.          |
| **API call**                            | Your backend starts the flow with typed inputs.                                  | Input schema, API token permissions, workspace, and idempotency.                       |
| **Webhook received**                    | Another system posts an event to Distro.                                         | Webhook setup, authentication, payload schema, and lead identity paths.                |
| **Meeting lifecycle**                   | A meeting is booked, rescheduled, cancelled, reassigned, or marked as a no-show. | Selected statuses, event types, and booking source filters.                            |
| **Scheduler displayed**                 | A workflow scheduler is displayed.                                               | Scheduler and event filters.                                                           |
| **HubSpot record created / updated**    | An eligible HubSpot record event reaches Distro.                                 | CRM connection, object, properties, and start conditions.                              |
| **Salesforce record created / updated** | An eligible Salesforce record event reaches Distro.                              | CRM connection, supported object, permissions, and subscription readiness.             |
| **Company identified**                  | Your identification provider posts an authenticated company event.               | Identification endpoint, authentication, company domain, and visit identity.           |
| **Visitor identified**                  | Distro identifies a visitor by email or company.                                 | Identity condition and the configured website source.                                  |
| **On a schedule**                       | The workflow should start at a defined time or interval.                         | Schedule setup, timezone, inputs, and missed-occurrence behavior.                      |

Availability depends on the connected tools and activation for your workspace.

## Form triggers

Save the form questions first, select the form in **New form submission**, and use **Refresh form connection** after changing its fields.

For a native form, publish the workflow and select that version in the form's routing settings. For an external form, activate the connection against a compatible published workflow.

See [Native lead forms](/forms/lead-forms.md) and [Connect an existing form](/forms/existing-forms.md).

## CRM start conditions

Use the trigger's start conditions to avoid running on every record event. For example, start only when a lead reaches your chosen status.

Updated-record workflows can write back to the same CRM. Choose conditions that prevent your own update from repeatedly starting the flow.

## Visitor actions need a visitor session

Forms in browser mode, extension starts, and API starts can support scheduling responses through their respective sessions.

A background form or ordinary webhook is not a browser page. Use notifications and CRM actions there; use a browser-capable source when the journey needs Show Scheduler or Redirect.

**Company identified** does not mean every anonymous visitor has been identified. It requires a configured source that provides the company event.


---

# 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 following URL with the `ask` and `goal` query parameters:

```
GET https://docs.distro.so/workflows/triggers.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 `build a script that syncs our docs to a CMS` 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.