Skip to main content
Triggers define the event that starts a workflow. Each workflow has exactly one trigger, and it is always the first step on the canvas. When the event occurs, a new run starts and follows the workflow’s steps, taking whichever branches its conditions lead to. Triggers only start runs while the workflow is Live, and every run uses the workflow’s latest published version. Many triggers accept optional filters to narrow which events start a run. For example, a Form Submission trigger can be filtered to a specific form, or an Inbound Call trigger to a specific phone number. When no filter is applied, the trigger fires for any matching event across your team.

Trigger Types at a Glance

Trigger Types

Webhook

Triggered by an incoming HTTP POST request to a unique webhook URL. Use this to connect external systems, third-party services, or custom applications to your workflows. When you select the Webhook trigger, your workflow automatically receives a unique URL in the format:
This URL is displayed on the trigger card and in the trigger’s configuration panel, with a copy button. Share it with the external system that should start your workflow. The system sends a POST request with a JSON body to this URL, and a run starts. Available Filters: None. The webhook URL is unique to your workflow. Each run can read the request through template variables:
  • {{trigger.body.field}}: A field of the JSON body. If the body is not valid JSON, the run starts with an empty body.
  • {{trigger.headers.Header-Name}}: A request header. The Authorization, Cookie, and X-Forwarded-For headers are not kept.
  • {{trigger.query.param}}: A query string parameter.
You can test webhook triggers by sending a POST request with a JSON body using tools like curl, Postman, or any HTTP client.

Response

The webhook endpoint responds right away: it creates the run and returns, and the steps run in the background. A successful response looks like:

Idempotency

To make retries safe, include an Idempotency-Key header on your POST request. If the same key is sent to the same workflow again within 24 hours, Dimedove returns the original run’s workflow_run_id instead of creating a new run, and the response body sets idempotent_replay: true. Keys are scoped per workflow: the same key sent to two different workflows produces two distinct runs. Use any opaque string your script can regenerate deterministically (a UUID, a hash of the payload, etc.).
Including this header is strongly recommended for any script that may retry on network failures. Without it, every request starts a new run. For receiving events from Dimedove in your own external systems (the reverse direction), see Webhooks.

Manual

Triggered manually from the dashboard. This is useful for testing workflows, running one-off automations, or running a workflow once for every person on a list. The Manual trigger has nothing to configure. When the published workflow uses a Manual trigger, a Run button appears in the workflow header. It is available only while the workflow is Live and has no unpublished changes; otherwise it is greyed out, and its tooltip tells you what to do first.
  • Run (or Run once in its menu) starts a single run right away and opens the Runs tab.
  • Run for a list in its menu starts one run per row of a file you upload. See Run for a List.
A single manual run starts with empty trigger data, so variables that read trigger.body resolve to empty text. Available Filters: None.

Run for a List

Use Run for a list to run a workflow once for each person in a spreadsheet, for example to start a follow-up sequence for a list of leads. It is available for workflows with a Manual trigger and no Call step. To call a list of people, use outbound calls instead.
1

Open the list sheet

Click the arrow next to Run and choose Run for a list. Optionally give the list run a Name: it is set once, when you upload the list.
2

Upload your list

Upload a CSV or Excel file of up to 25 MB and 10,000 rows with an email or phone_number column (Download template gives you a starting point). Every other column is available to the workflow as {{trigger.body.<column>}}: under Detected columns, click a column to copy its variable. Rows that cannot be used are skipped and counted.
3

Choose when

Choose Run now, or Schedule for later and pick a date and time at least 5 minutes ahead.
4

Confirm and start

Tick the checkbox confirming that every recipient consented to receive messages from you. If the start time falls outside standard contact hours (8 AM to 9 PM), also acknowledge that. Review the estimated credit cost, then click Run (or Schedule).
Each row becomes its own run, on the version that was published when you submitted the list. Each row is matched to a contact (a new contact is created when none exists), so steps such as Wait for event can wait for that person’s reply. Addresses and numbers that opted out, and blocked contacts, are skipped. Runs start gradually rather than all at once, and only between 8 AM and 9 PM in your time zone, unless you acknowledged starting outside those hours: a list that is still starting at 9 PM continues the next morning. While the workflow is paused, the list waits; after about a week without progress, it stops. List runs appear under List runs, above the runs table, with counts of total, enrolled, running, completed, failed, and skipped rows. Click a list run to filter the runs table to its runs, or click Recipients to see what happened to each uploaded row (Queued, Enrolled, Skipped, or Failed, with the reason). Cancel stops a list run: no more runs start, and the runs it already started are cancelled too. Runs that already finished keep their result.

Qualified Opportunity

Triggered when one of your agents records a qualified opportunity during a conversation. This connects your agent’s performance tracking to downstream automations, allowing you to instantly act on high-value leads. Use cases include notifying your sales team, pushing qualified lead data to your CRM via an HTTP request, or starting a follow-up goal. Available Filters:
  • Filter by Agent: Restrict the trigger to qualified opportunities recorded by a specific agent. Leave it on Any agent to fire for any agent on your team.
  • Filter by Channel: Restrict the trigger to opportunities from a specific channel: Web, Forms, Calls, SMS, Slack, Emails, Socials (Facebook Messenger, Instagram, and TikTok direct messages), or Apps (conversations from your Apps). Leave it on Any channel to fire for any channel.
See Agent Performance for details on how qualified opportunities are recorded.

Human required

Triggered when an agent requests human assistance during a conversation. Use this to notify your team immediately when a conversation needs human intervention, whether by emailing a teammate, posting to a Slack channel, or triggering an external notification system. Available Filters:
  • Filter by Agent: Restrict the trigger to human assistance requests from a specific agent. Leave it on Any agent to fire for any agent.
See Human Fallback for details on when and why agents escalate to humans.

Form Submission

Triggered when a form submission is completed. Use this to send collected form data to external systems, notify your team, update your CRM, or trigger follow-up actions based on the submitted information. Available Filters:
  • Filter by Form: Restrict the trigger to submissions from a specific form. Leave it on Any form to fire for any form on your team. When you pick a form, its fields are offered as variables such as {{trigger.body.form_data.email}}.
The dashboard displays a warning indicator next to forms that are currently disabled. Disabled forms will not generate submissions, so the trigger will not fire for them.
See Forms for details on form configuration and data collection.

Email Received

Triggered when an inbound email arrives at one of your email channels and your agent handles it. Emails in a conversation a teammate has paused, and opt-out requests, do not start runs. Use this to trigger actions based on incoming customer emails, such as forwarding data to an external system, notifying a Slack channel, or starting a follow-up workflow. Available Filters:
  • Filter by Email Channel: Restrict the trigger to emails received on a specific email channel. Leave it on Any email channel to fire for any email channel on your team.
The dashboard displays a warning if the selected email channel is currently disabled. Disabled channels will not receive emails, so the trigger will not fire.
See Email Channels for details on email channel setup and configuration.

Inbound Call

Triggered when an inbound phone call on one of your team phone numbers ends. The trigger data includes the call’s duration and a summary of its transcript. Use this to trigger post-call actions such as sending a follow-up email, notifying your team, or logging call data to an external system. Available Filters:
  • Filter by Phone Number: Restrict the trigger to calls received on a specific phone number. Leave it on Any phone number to fire for any phone number on your team.
The dashboard displays warnings if the selected phone number is disabled or does not have calls enabled.
See Telephony for details on phone number configuration.

Inbound SMS

Triggered when an inbound SMS message is received on one of your team phone numbers and your agent handles it. Messages in a conversation a teammate has paused, and opt-out keywords such as STOP, do not start runs. Use this to trigger actions based on incoming text messages, such as forwarding the message content to a Slack channel or logging it in an external system. Available Filters:
  • Filter by Phone Number: Restrict the trigger to SMS received on a specific phone number. Leave it on Any phone number to fire for any phone number on your team.
The dashboard displays warnings if the selected phone number is disabled or does not have SMS enabled.
See Telephony for details on phone number configuration.

Slack Message Received

Triggered when a Slack message is received in a channel where a Slack Agent is deployed. This includes both direct @mentions and messages in threads where the agent is participating. Use this to trigger actions based on Slack activity, such as logging messages or triggering external processes. Available Filters:
  • Filter by Slack Agent: Restrict the trigger to messages received by a specific Slack Agent. Leave it on Any Slack Agent to fire for any Slack Agent on your team.
The dashboard displays a warning if the selected Slack Agent is currently disabled. Disabled agents will not receive messages, so the trigger will not fire until the agent is re-enabled.
See Slack Agents for details on deploying agents to Slack channels.

Contact Created

Runs once when a new contact is captured with its initial data, for example when someone first reaches out on one of your channels or shares their details with your agent. Use this to welcome new leads, enrich them, or hand them to an agent as a goal. Available Filters:
  • Filter by Agent: Restrict the trigger to contacts captured by a specific agent.
  • Filter by Channel: Restrict the trigger to contacts who came in on a specific channel (same options as for Qualified Opportunity).
The trigger data includes the contact’s attribute values, available as {{trigger.body.attributes.<key>}} (for example {{trigger.body.attributes.email}}).
Contact triggers never fire for contacts that only exist in preview conversations, and never for edits a teammate makes to a contact in the dashboard.
See Contacts for details on contacts and their attributes.

Contact Updated

Runs when a contact’s attribute values change, for example when your agent learns a phone number during a conversation or an enrichment step fills in a job title. Available Filters:
  • Filter by Agent and Filter by Channel: The same filters as Contact Created.
  • Filter by Attributes: Only fire when at least one of the selected attributes changes. Leave it empty to match any attribute.
  • Filter by Change Source: Only fire for the selected sources: Insights (values your agents pick up in conversations) or Enrichment (values written by enrichment and by workflow steps). Leave it empty to match any source.
The trigger data includes the contact’s current attribute values ({{trigger.body.attributes.<key>}}), the list of attributes that changed (changed_attributes), and what changed them (change_source). A new contact’s first data starts Contact Created, not Contact Updated. The exception is a Contact Updated trigger filtered to particular attributes: it also fires for a new contact whose first data includes one of them.
Edits a teammate makes in the dashboard never fire contact triggers. When a workflow step changes a contact (Update contact attribute or Enrichment), it can start other workflows’ Contact Updated triggers, but never the workflow that made the change.

Schedule

Runs on a recurring schedule (cron), for example to send a weekly report or check an external system every morning. The workflow runs at each scheduled time while it is Live. Settings:
  • Frequency: Pick a preset: Every 15 minutes, Every hour, Every day at 9:00, Weekdays at 9:00, Every Monday at 9:00, or 1st of the month at 9:00, or choose Custom. New schedules start on Weekdays at 9:00.
  • Cron expression: The schedule as 5 fields: minute, hour, day of month, month, and day of week (for example 0 9 * * 1-5). Runs must be at least 15 minutes apart.
  • Timezone: The time zone the schedule follows (America/Toronto by default).
The scheduled time is available as {{trigger.body.scheduled_at}}. Available Filters: None.

Goal completed

Runs when an agent finishes a goal, whether the goal completed, failed, or was cancelled. Use this to report outcomes, update an external system, or start the next stage of a process. Available Filters:
  • Filter by Agent: Restrict the trigger to goals pursued by a specific agent.
The trigger data includes the goal’s title and its final status (completed, failed, or cancelled). To act only on goals that were reached, add a Condition on trigger.body.status right after the trigger.
A goal started by a workflow’s Start goal step never starts that same workflow’s Goal completed trigger. To continue a workflow when its own goal finishes, turn on Wait for completion in the Start goal step instead.

Approval decided

Runs when a teammate approves or rejects a request, whether it came from a goal (see Tasks and Approvals) or from a workflow’s Approval request step. The trigger data tells you whether the request was approved (approved) and who decided (decided_by). Available Filters: None.

Note created

Runs when a note is added to a contact, a conversation, or a goal, such as the note your agent files after a conversation. The trigger data includes the note’s title and, when the note is about a contact, its contact_id. Available Filters: None. See Notes for details on notes.

How Trigger Filters Work

Filters give you precise control over which events start your workflow:
  • Filter set: The workflow only fires when the event comes from the specific resource you selected (e.g., a particular form, phone number, or agent)
  • Filter unset (“Any”): The workflow fires for every matching event across your entire team
  • Several filters: An event must match all of the filters you set
  • Several values in one filter (Contact Updated attributes and change sources): The event matches when any of the selected values matches
You can combine a trigger type with filters to create targeted automations. For example:
  • “Fire only when the Sales Inquiry form is submitted”
  • “Fire when any agent on the team requests human help”
  • “Fire only when a contact’s phone number changes”

Accessing Trigger Data

All trigger data is available to your steps through template variables. Use {{trigger.body.field_name}} in any text field to reference data from the event. When you configure a step, its panel lists the Available trigger data: for the workflow’s trigger: click a variable to copy it. For contact triggers, the list also includes each of your contact attributes as {{trigger.body.attributes.<key>}}, and for a Form Submission trigger with a form selected, each form field as {{trigger.body.form_data.<key>}}. Commonly used fields include: Attributes treated as sensitive, such as addresses or policy numbers, are left out of contact trigger data. You can inspect the exact data for any run by opening its run logs in the Runs tab. This is especially useful when building your first workflow or discovering which fields are available for a given trigger type.
A single manual run has no trigger data. To try a workflow on sample data, send a test request to a Webhook trigger (for example with curl), or use Run for a list with a one-row file that contains your own email address or phone number, then check the run logs to confirm your variables resolve as expected.