> ## Documentation Index
> Fetch the complete documentation index at: https://docs.os.default.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Triggers

> What starts a workflow: form submissions, incoming webhooks, meeting changes, website intent, and CRM records.

A trigger is what starts a workflow. Every workflow begins with exactly one trigger, and the
data the trigger carries (the submitted form, the webhook body, the meeting, the CRM record)
is available to the steps that follow.

<Note>
  Add a trigger when you create or open a workflow in the **Workflows** app, then build the
  steps that run after it fires.
</Note>

## Form submission

Fires when someone submits a form you track with Default.

* **Connected Form**: choose which tracked form starts the workflow. For example, pick your
  `Request a demo` form so every submission runs this workflow.

The submitted field values are available to later steps.

## Incoming webhook

Fires when an external system sends a request to a webhook URL Default gives you.

* **Connected Webhook**: choose an existing webhook to start this workflow, or create a new
  one.

The webhook's request body is available to later steps.

## Meeting status

Fires when a meeting changes status.

| Field                | What it does                                         | How to use it                                                                                                                              |
| -------------------- | ---------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------ |
| **Meeting statuses** | The status changes that start the workflow.          | Select one or more, for example **Held** and **No show**, to run the workflow when a meeting reaches either.                               |
| **Event types**      | Limits which kinds of scheduling events count.       | Optional. Choose one or more, for example **Team**, to react only to meetings booked through that kind of event. Leave empty to match any. |
| **Specific events**  | Limits the trigger to certain scheduling events.     | Optional. Choose one or more of your events by name. Leave empty to match any.                                                             |
| **Sources**          | Limits which meetings count by how they were booked. | Optional. Choose **Workflow** and/or **Booking link**. Leave empty to match meetings booked either way.                                    |

The meeting's details are available to later steps, including the meeting owner and any other
hosts, which you can insert from the data picker and map into owner or recipient fields (for
example, a CRM record's owner or a Slack recipient).

<Tip>
  Because each status is a fixed value rather than free text, later steps can branch on it.
  For example, add a branching step after the trigger to send **Held** meetings down one path
  and **No show** meetings down another.
</Tip>

## Website intent signal

Fires when a visitor to your site is identified. In the trigger picker, this appears as two
variants:

* **Account Signal**: identifies the visitor's company in real time, as the page loads.
* **People Signal**: identifies the visitor (name, title, email) in batches, roughly every 30
  minutes.

Opening the trigger's configuration shows the underlying fields, including a **Trigger type**
that can also be set to a third option, **Batched company (Vector)**, to identify the
visitor's company in batches instead of in real time.

| Field                | What it does                               | How to use it                                                                                                                                                                      |
| -------------------- | ------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Trigger type**     | How and when the visitor is identified.    | Choose **Real-time company**, **Batched company (Vector)**, or **Batched person (Vector)**. Adding the trigger as **Account Signal** or **People Signal** sets this automatically. |
| **Tracked domain**   | Limits the trigger to one of your domains. | Optional. Enter a domain, for example `default.com`; its subdomains match too.                                                                                                     |
| **Page URL pattern** | Limits the trigger to certain pages.       | Optional. Enter text the page URL must contain, for example `/pricing`.                                                                                                            |

## CRM record created

Fires when a record is created in a connected CRM. CRM triggers are available once Salesforce
or HubSpot is connected to your workspace.

| Field         | What it does                      | How to use it                                                                                                                   |
| ------------- | --------------------------------- | ------------------------------------------------------------------------------------------------------------------------------- |
| **CRM**       | Which connected CRM to watch.     | Pick **Salesforce** or **HubSpot**.                                                                                             |
| **Record**    | Which kind of record to watch.    | Pick the object, for example **Contact** or **Account**. The choices depend on the CRM you picked.                              |
| **Condition** | Limits which new records qualify. | Optional. Once you pick a **Record**, add criteria using its fields, for example only records where `Lead Source` is `Inbound`. |

## CRM record updated

Fires when a record is updated in a connected CRM. It uses the same fields as CRM record
created above (**CRM**, **Record**, and an optional **Condition**), but runs when a matching
record changes rather than when one is created.

{/* TODO screenshot: Meeting status trigger config with statuses, event types, and sources */}

{/* verified against product (origin/main):
   trigger labels + config fields
     → apps/default-api/src/server/modules/triggers/registry/definitions/{form-submission,incoming-webhook,meeting-status,website-de-anonymization,crm-object-created,crm-object-updated}.ts
   Account Signal / People Signal picker variants
     → apps/default-fe/src/app/(apps)/@workflows/workflows/_utils/registrySections.ts (TRIGGER_VARIANTS)
   Meeting statuses real labels (Booked/Rescheduled/Held/No show/Canceled, not Completed/Cancelled)
     → meeting-status.ts meetingStatusLabels; branch-by-status capability → commit 9e75f169c (#2330), logic.ts "Multi-Branch" node
   CRM trigger field labels "CRM" / "Record" (not "Provider" / "Record type") + inline dropdowns replacing tree selection
     → commit bdcf82de1 (#2198), crm-object-created.ts / crm-object-updated.ts

 re-verified against product (origin/main as of 2026-07-18):
   trigger type roster unchanged: still exactly these 6 (Form Submission, Incoming Webhook, Meeting Status,
   Website Intent Signal, CRM Record Created, CRM Record Updated); no adds, removes, or renames
     → packages/shared/src/constants/triggers.ts (TriggerType, TRIGGER_TYPE_LABELS)
   Account Signal / People Signal picker variants unchanged (still exactly 2, no third picker variant added)
     → apps/default-fe/.../_utils/registrySections.ts (TRIGGER_VARIANTS, unchanged)
   CRM record created/updated: the "Condition" builder can also condition on which fields changed (not just their
   values) for the updated kind ("Fields Updated"); this is an existing capability of the Condition field, not a
   new change since the last pass, so left undocumented at the current level of detail
     → apps/default-fe/.../_components/config-fields/ConditionBuilderConfigField.tsx (supportsFieldsUpdated)
   Meeting Status trigger, RESOLVED (was flagged not-verifiable in the filtered snapshot): the trigger's config/setup
   fields did NOT change, so the field table above stands as-is. What changed is the trigger's data-schema
   presentation: the primaryHost field's display name was renamed to "Meeting owner", and every host user-object id
   leaf is now tagged (format 'id' + user semantic) so it can be mapped into owner/recipient fields (Contact owner,
   Slack recipient, etc.) from the variable picker. Added one prose sentence after the field table covering meeting
   owner/hosts data flowing to later steps; deliberately no field-by-field payload listing (page stays at
   config-field granularity)
     → apps/default-api/src/server/modules/triggers/registry/index.ts, commit 62f03696c (#2810)
   Test button behavior for these triggers (condition-aware CRM starter, blank pre-filled keys, Meeting Status not
   yet testable) is documented in workflows.mdx's "Test a workflow" section instead of here, to avoid duplication
     → apps/default-fe/.../testing/crmTestStarter.ts, apps/default-api/.../workflows/testing/kinds.ts
   NOTE: labels are registry-driven (served from default-api, not literal strings in default-fe), so the alignment
   lint may false-flag them. */}