Skip to main content
A workflow can hold more than one trigger block, and the palette offers up to thirteen kinds: eleven that react to something one lead just did, and two that instead go looking for whichever leads match a filter.
Where
OutreachWorkflow Builder
Your role needs
Create access to Workflow Builder create-workflows. Admin and Member have it by default.
To create or change
create-workflows to add one, update-workflows to change one, on top of the permission above.
Not listed in the sidebar today; reachable from the surfaces that link to it, and by URL. If you cannot find this in your sidebar, your workspace may have a custom menu configuration. Contact support and we will check it for you.

What each trigger does

Manual / Test is the only trigger limited to one per workflow: add a second and nothing happens, and its Duplicate button is disabled. Every other trigger can appear as many times as you want, each with its own filters.

Most triggers react; two go looking for leads instead

Eleven of these triggers arrive already holding the one lead they concern: a tag lands on a lead, a lead sends a WhatsApp message, a lead books a meeting. Each occurrence enrolls that one lead and nobody else. On a Date or Schedule and Time Since Event work differently. No single lead does anything to start them: time simply passes, and a scanner goes looking for whichever leads match right now. One occurrence of either can enroll many leads at once, which is why they are the only two triggers whose inspector shows a live “leads match” chip, backed by the same query the scanner itself runs.

The audience filter, and where it is required

Both time triggers carry Only leads in stage and Only leads with tag. On a Date or Schedule carries two more that Time Since Event does not have at all: Only leads from, which narrows by how the lead first arrived (a search, an import, a manual add, an automatic add, the website tracker, WhatsApp, a web form or Instagram) rather than by which saved search found it, and the Every lead in the workspace toggle. What differs between the two triggers is whether leaving everything empty is allowed. Set When to Repeating and the trigger will not activate unfiltered: pick a stage, a tag or an origin, or tick Every lead in the workspace to confirm you mean everyone. Saving is never what stops you. Save stores the graph exactly as it stands, on the canvas and on the server, and the check runs when you press Activate, which opens the validation panel instead of activating. Switch When back to On a date and the requirement disappears entirely: an unfiltered one-off date activates and runs as configured, enrolling every lead in your workspace once, on that date. Time Since Event carries no such guard, in either direction. It has no Every lead in the workspace toggle to begin with, and nothing stops it activating with both Only leads in stage and Only leads with tag empty. Leave it that way and every lead that reaches the chosen anchor enrolls, for as long as the workflow stays active. Time Since Event only ever looks forward. Activating it stamps a starting line, and only leads whose anchor date lands from that point on are ever considered, so a lead whose meeting was scheduled last month does not retroactively enroll. Changing Count from, Fire or How long moves that starting line to the moment the change takes effect. Widening Only leads in stage or Only leads with tag does not: audience filters are deliberately left out of that reset, so a wider audience changes who qualifies from then on rather than pulling in leads whose moment already passed.

Which triggers you’ll actually see

The registry behind the palette defines seventeen trigger types. Four of them never reach a live workflow, for two different reasons. Facebook Message Received is flagged in the builder as not built yet, and a block flagged that way is dropped from the palette rather than shown and labelled. There is no visible “coming soon” marker anywhere in the builder, so the block simply is not in the list. Email Opened, Link Clicked and Instagram Comment Received are quieter cases. Nothing flags them, but the backend never reports them as executable, and the palette hides anything it cannot run, the same treatment an unbuilt block gets. A saved graph containing one of these three fails to activate outright, with an error naming the block as not available yet. Form Submitted is the opposite kind of missing: it is fully wired end to end, and it only appears where web forms are switched on. That is a platform-wide switch rather than something a workspace turns on for itself, so if the block is absent, the sidebar’s Web Forms entry is absent too. See connecting a web form. The remaining channel triggers work a third way. WhatsApp Received, Instagram DM Received and MercadoLibre Question Received stay in the palette even without a connected account: they show dimmed, carrying a Connect WhatsApp (or Instagram, or MercadoLibre) chip instead of disappearing, and hovering one says Connect WhatsApp to use this block. LinkedIn Invite Accepted is the one exception. Nothing gates it behind a connected LinkedIn account, so it shows as fully usable whether or not you have one, even though what fires it is a LinkedIn invitation you sent being accepted.

Reply Received only matches email, right now

The block’s own description says it starts “when the lead replies by email or LinkedIn,” but its Channel field offers exactly one option: Email. Inbound LinkedIn replies are captured elsewhere in the product and deliberately deferred to a later phase, so picking this trigger only ever starts a run from an email reply today, whatever the description implies.

Enrollment quirks tied to specific triggers

Once a lead enrolls through a given trigger on a given workflow, that same trigger does not enroll it again, ever, even after the run finishes. Two triggers ship with a looser default: MercadoLibre Question Received and Website Visited re-enroll a lead on their next occurrence as soon as no run for that lead is still going, because a second question or a second visit is the normal case for either of them, not an edge case. A run already in flight still blocks a new one. Meeting Booked stays at the stricter “never again” default on purpose. A rescheduled meeting updates the same booking rather than creating a new one, so re-running the workflow on a reschedule would just repeat itself. Booking a meeting also pauses the lead’s own automation, and every path that books one does that before this trigger fires. Meeting Booked is exempt from that pause: it is the one trigger allowed to run its own steps on a lead whose automation is otherwise off, so a confirmation step chained off this trigger still sends. The exemption is stamped with the moment it was granted, so someone pausing that lead by hand afterwards stops the run normally.

Four triggers ignore events that are too old

WhatsApp Received, Instagram DM Received, MercadoLibre Question Received and LinkedIn Invite Accepted all check when the thing actually happened before enrolling anyone, and skip it if that moment is older than a set window. Each reads its own clock: the message’s receipt time, the question’s ask time, the invitation’s acceptance time. That is what stops reconnecting an account, backfilling a history, or re-syncing old conversations from mass-enrolling everything at once as if it had all just arrived. A MercadoLibre question released from moderation is the one exception, and counts as live however old it is, because the seller has only just been allowed to answer it. Reply Received carries no such check. It fires the moment an inbound email is saved against the lead, with nothing looking at how old the email itself is.

Canvas, palette and inspector

Add and connect blocks, and read what the toolbar and inspector are telling you.

Enrollments and the lead journey

What a trigger firing actually looks like from the lead’s own page.

Lead stages and the funnel view

The six fixed stages every Only leads in stage filter picks from.

Tags

How a tag lands on a lead, and why so many triggers filter on it.