Triggers

Every workflow begins with a trigger, the event that fires it. The trigger you choose determines who starts the flow, when it runs, and what starting context the run receives.

Ticket trigger

The workflow starts automatically when a ticket is created, or a new message arrives on an existing ticket, that meets the trigger criteria, such as arriving in a specific inbox or matching a tag. Use it for triage (first response, categorization, routing) and for follow-up (adding internal notes, requesting missing information, kicking off downstream steps). The run has access to the full ticket, the sender, and the message from the start.

A ticket trigger can fire more than once on the same ticket, for example on each new message. Design steps to be safe to run again, or add conditions that prevent duplicate actions. Messages posted by the workflow itself are ignored as triggers, so a flow does not re-trigger itself forever; see Workflows and tickets.

Chat trigger

A team member or admin runs the workflow by name from the Harriet chat interface, and the run receives the user's message as its starting context. Use it for on-demand processes: handing off a qualified lead, logging a new vendor, or kicking off a compliance check. In Settings → Triggers, you can require admin approval before a chat run starts, and turn on ticket creation so the run gets a tracked thread. New workflows leave ticket creation off. When a ticket is created, the user then interacts with the workflow through that ticket. Triggering a workflow from chat requires an admin to enable it on that channel.

Scheduled trigger

The workflow runs on a recurring schedule, for example every Monday morning or the first of each month. Use it for proactive work: regular reminders, compiled reports, and checks for overdue items. No human starts it and no ticket exists unless the workflow creates one to surface information to your team. Scheduled runs covers this trigger in depth.

Webhook trigger

An external system calls a Harriet URL to start the workflow, passing structured data in the request. Use it for integration-driven events: a CRM fires when a deal closes, or an IT tool notifies Harriet that a software license is expiring. The run receives the webhook payload as its initial context, so fields like name, email, account, and renewal date become variables the workflow can reference throughout. Webhook triggers require IT to register the Harriet webhook URL in the calling system and confirm which fields the payload sends.

What the trigger hands the run

For the details of when Harriet creates a ticket for a run and when it does not, see Workflows and tickets.