Skip to main content
A trigger is what starts a workflow. Every workflow begins with exactly one trigger. The nodes that follow can use the data the trigger carries, such as the submitted form, the webhook body, the meeting, or the CRM record.
Add a trigger when you create or open a workflow in the Workflows app. Then build the nodes that run after it fires.

​
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.
Later nodes can use the submitted field values.

​
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.
Later nodes can use the webhook’s request body.

​
Meeting status

Fires when a meeting changes status. Later nodes can use the meeting’s details, including the primary host and any other hosts. Insert them from the data picker. When a teammate made the booking, for example from the Chrome extension, the picker also offers Booked by: that teammate’s name, email, and ID. You can map them into owner or recipient fields, for example a CRM record’s owner or a Slack recipient.
Because each status is a fixed value rather than free text, later nodes can branch on it. For example, add a branching node after the trigger to send Held meetings down one path and No show meetings down another.

​
Website intent signal

Fires when Default identifies a visitor to your site. 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’s name, title, and email in batches, roughly every 30 minutes.
Open the trigger’s configuration to see the underlying fields. The Trigger type field has a third option, Batched company (Vector), which identifies the visitor’s company in batches instead of in real time.

​
CRM record created

Fires when a new record appears in a connected CRM. CRM triggers become available once you connect Salesforce or HubSpot to your workspace.

​
CRM record updated

Fires when a record changes in a connected CRM. It uses the same fields as CRM record created above: CRM, Record, and an optional Condition. The trigger fires when a matching record changes, not when a new record appears.

​
Extension

Fires when a rep books or routes a lead from the Default Chrome extension. Email is always collected, and on its own it is enough to route a lead. Nothing else is required to publish or use the trigger.
  • Connected Form is optional. Connect one when reps should fill in more than the email. Reps then fill out that form’s fields in the extension before the workflow runs, and the submission is recorded against the form like any other submission.
  • Email fields on a connected form are filled from the lead’s email automatically.
  • Create or edit the form’s fields in Forms. Set Maps to on a field so the extension can prefill it from the lead’s record and the meeting keeps the lead’s name and phone.
  • One form can be connected to several Extension or API triggers.
Later nodes can use the rep’s responses as trigger data. The data picker also offers Booked by: the rep who routed the lead, with their name, email, and ID. You can map it into owner or recipient fields, for example a CRM record’s owner or a Slack recipient, and pick it as a host on a Display scheduler node so the rep’s and the assigned host’s availability are shown together.