Where
Outreach→Workflow 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.
The palette group named CRM is not where Send to CRM lives. That group holds Change Lead Stage, Tag Lead and the other blocks that change the lead’s own record inside this product. The three blocks that talk to an outside system sit further down, under Integrations. Run Workflow sits further up, in Outreach, alongside the blocks that send.
A block gated on a connection is never hidden. It stays in the palette, dimmed, with a badge and tooltip naming what it needs, exactly as Canvas, palette and inspector describes. That page covers the mechanic; this one covers what each of the four actually does once you’ve added it.
Send to CRM
Send to CRM creates or updates the lead in whichever integration you pick: HubSpot, Salesforce, Odoo, Kommo, HeyReach, or a saved webhook connector. It runs the same push as the Push to CRM button on a lead and as a workspace’s own auto-push setting; all three call the same service. Slack is left out of the picker on purpose: Slack is a notification, not a place a lead’s record can live. You need at least one of those six connected before you can add the block, and the palette’s dimmed badge always reads “Connect HubSpot”, even when connecting Salesforce, Odoo, Kommo, HeyReach or a webhook would unlock it just as well. HubSpot is simply first on the list the badge reads from. If a block already on your canvas loses its connection later, the Validation panel is more specific: its error names every type that would fix it, not just HubSpot. Connect a CRM from ; each vendor’s own connect page covers the setup. Auto-push and stage filters explains the separate, always-on push that runs without a workflow at all, which this block sits alongside rather than replaces.Notify on Slack
Notify on Slack posts a message you write to a connected Slack channel. The message is required, so the workflow will not activate with the field empty. There is no separate channel field. The picker in the inspector is labeled Slack channel and lists your Slack connections, because each connection posts to the one channel its webhook was created for. Connect a second Slack webhook to post somewhere else. This is the one block of the four that never branches. A team notification is a side effect of the lead’s journey, not a decision point in it, so the flow always carries on to whatever comes next. A temporary failure (Slack’s servers, a network blip) retries on its own; a permanently broken connection, such as a revoked webhook or an archived channel, is skipped without stopping the lead.Send Webhook
Send Webhook sends the lead to any HTTP endpoint, chosen between two sources: Custom URL, a one-off endpoint typed straight into the block, or Saved connector, which reuses a webhook connector’s own URL, method, authentication and field mapping from . Either way, every value you type, the URL included, can carry a merge tag like{{lead.email}}.
On a custom URL, Method and Body format (JSON or Form) default to POST and JSON. Below those sit two key/value lists, Headers and Fields to send: click Add field for another row in either, and every row in Fields to send gets a braces button that inserts a lead value without you typing the tag. Repeat a key and the later row turns red, with a note that only the last one is sent. A custom URL always carries the event type, the lead’s ID, the workflow’s ID and a timestamp, even if you map nothing else. A saved connector’s payload comes from the connector’s own field mapping instead, with anything you add in Fields to send merged on top.
Leaving the endpoint URL blank on a custom URL block is a validation error, not just a runtime one. It keeps Activate disabled, and the Validation panel lists it as “Add the endpoint URL to send to.”
See Webhook testing and delivery rules and Connect a webhook for retry behavior and how a saved connector’s own mapping works.
Run Workflow
Run Workflow hands the lead to another workflow as a reusable sub-flow, then carries straight on itself. The two do not wait on each other: the sub-flow gets its own enrollment, its own cursor, timers and retries, entirely separate from this one. It branches Started when the sub-flow was enrolled. It branches Skipped when enrollment declined, and there are several honest reasons for that: the target workflow is not active, the lead has already been through that sub-flow, the lead’s automation is paused, the workspace is at its cap on running enrollments, or the chain has hit its depth cap. A chain of Run Workflow blocks can nest five deep before the next one is refused. Every sub-flow in a chain enrolls a lead at most once, whatever the target’s own re-enrollment setting says. That is what stops an accidental loop from A to B and back to A becoming a runaway enrollment storm. Two cases are not a skip. Pointing a workflow at itself fails the block, and so does picking a workflow that has since been deleted. In both, the lead’s run stops there and ends as failed.Related
Auto-push analyzed leads and stage filters
The always-on push that runs whenever a lead reaches a stage, without any workflow involved.
Connect a webhook
Set up a saved connector: the endpoint, authentication and the field mapping this block can reuse.
Field mapping reference per CRM
The fields each CRM actually receives, and why only one CRM can ever own a lead.
Webhook testing, delivery rules and record IDs
How a delivery is judged a success or failure, and what gets retried.