Webhook-triggered workflows: letting outside systems move your CRM

Tuesday, 9:12 a.m. The billing provider had already flagged seven failed card charges at 3:40 that morning. The notice landed in a shared inbox and sat there. The operations lead sees it when she opens the inbox. In the five and a half hours in between, none of the seven customers were contacted, no task was created, and two of them had already closed their accounts. Nobody made a mistake. The information existed; it just never reached the CRM.

This piece is about the connection that removes those five and a half hours: an event announced by an outside system starting a workflow inside your CRM directly. We start with what an incoming request actually is and is not, then work through which events deserve a workflow, how webhooks compare with scheduled polling, how payload fields map onto records, how you verify the sender, why the same event arriving twice is expected rather than broken, how failed runs get recovered, how a flow is rehearsed before it goes live, how sudden bursts are kept away from customers, and where automation should stop and hand over to a person.

Is an incoming webhook a notification or an instruction?

A request from an outside system is a claim about the world: "this happened at this time." It is not an order. The distinction sounds academic and it decides everything about the setup. An endpoint that accepts orders writes every mistake the other system makes straight into your data; one stray request from a sandbox and a real customer gets a real message. An endpoint that accepts claims asks first: do we have this record, is it already in this state, does this event concern us at all.

In practice that means the first step of the flow is a condition, not an action. The Conditional Branching step in Workflow Builder does exactly this work: one branch when the status field reads "failed," another when it reads "refunded," and no branch at all when the value is one you have never seen, in which case the run ends quietly. Putting the condition first makes the rest of the flow easier to write, and the wider logic of rule-driven flows is laid out in our piece on automating processes with conditional rules.

The second payoff arrives the day the provider changes its contract. A field gets renamed, a new status value appears, the payload gains another wrapper. A flow that takes orders does the wrong thing perfectly well. A flow that evaluates claims finds no match and stops. Noticing a stopped flow is far easier than noticing a flow that has been quietly wrong for a fortnight.

Which external events deserve a workflow at all?

Not every event is worth a flow. A useful filter: when this arrives, will a person behave differently? If not, the event is a log line, not a trigger. A payment failed, a trial expired, a support ticket was reopened for the second time, a renewal date is thirty days out — each of those requires someone to do something. "User changed their profile photo" can be written to the record, but it should never wake anyone up.

The second filter is decay. If the value of the event evaporates within hours, a webhook is the right instrument; if it lasts days, an overnight sync will do. A slot filled through a scheduling tool belongs firmly in the first group, because the customer can cancel within the hour; how that path is wired end to end is covered in our piece on booking links that write straight into the CRM.

The third filter is ownership. If the work triggered by an event does not land on a named person, do not build the flow; an alert nobody owns becomes background noise within three weeks. When your form sits on your own stack and cannot write to the CRM directly, the webhook is the bridge — and its effect shows up in the numbers discussed in turning visitors into leads on a landing page, because the minutes between submission and first contact fall sharply.

Webhook, scheduled pull, or manual entry?

These three are not competitors; they are right for different jobs. A webhook is the other system telling you. A scheduled pull is you asking at intervals. Manual entry is for low volume with fuzzy rules. The criteria that decide between the first two are short:

Criterion	Webhook (pushed)	Scheduled pull
Latency	Seconds	As long as the interval
Missed events	Lost if the request fails; retries are mandatory	Picked up on the next pass
Load	Only when something happens	Every cycle, event or not
Setup cost	Endpoint and signing secret on the sender's side	Auth, pagination, a high-water mark
Best suited to	Single events needing an immediate response	Bulk sync and end-of-day reconciliation

Mature setups usually run both: the webhook supplies speed and the nightly pull is the safety net that catches whatever was dropped. For a side-by-side look at the different ways of wiring tools together, see our overview of API and webhook options for CRM integrations.

How do you map payload fields onto CRM records?

Mapping is the dullest and most decisive part of the build. Identity comes first: which field in the payload corresponds to your record? An email address is convenient and brittle, since the same person may sign up twice with different addresses. Storing the sender's own identifier in a field on the CRM record and matching on that removes half the problems you would otherwise hit six months in.

Conversion comes next. Are amounts sent in minor units, which time zone are the timestamps in, are status values uppercase? Write the answers down before you build, because every one of them can be wrong silently. Then decide what happens when a field is simply absent: does the flow halt when no phone number arrives, or continue with the field empty?

Finally, keep the mapping in one place. If five event types from the same provider each repeat the same conversion in their own flow, a single renamed field means five edits. The Sub-workflow Call step lets you collect shared mapping steps into one flow and call it from the others, with loop and depth guards keeping the chain from calling itself.

How do you know the sender really is that system?

A webhook endpoint is exposed to the internet. Its address may be hard to guess, but it is not a secret: once it leaks, anyone who can reach it can start a workflow in your CRM. That is why you verify the signature on the request rather than trusting the contents of the payload. The provider signs the body with a shared secret, you recompute it, and a mismatch means the request is never processed.

Two things sit alongside the signature: a timestamp check and an event identifier. The timestamp stops an attacker replaying a request captured months ago — anything outside a narrow window is rejected outright. We covered the mechanics separately in our piece on signature verification and replay protection.

The third layer is authorisation. A signature tells you who sent the request, not what it may do. An event from a billing provider moving a deal to a different stage is reasonable; the same event deleting a user is not. Narrowing what a flow may do based on where the event came from limits the blast radius if a secret ever leaks.

What should happen when the same event arrives twice?

Duplicates are not a fault; they are part of normal operation. If the provider does not receive your acknowledgement in time, it sends the request again. A network blip, a restart, or a slow response on your side all produce the same event landing twice and occasionally three times. A flow that ignores this sends the customer the same message twice, opens the same task twice, and splits one deal into two.

The fix is to use the event's own identity. Store the unique event identifier the provider sends, and make the first condition of the flow ask whether that identifier has already been handled; if it has, the run ends without doing anything. When no identifier is supplied, build your own key from the record id, the event type, and a timestamp rounded to the minute.

This check is the precondition for handing repetitive work to triggers at all — otherwise automation spends the time it saves on cleanup. The consequence on the task side is described in lifting repetitive work with no-code triggers: the second time a duplicate task appears, the rep stops trusting the automation and goes back to doing it by hand.

Who picks up the pieces when a step fails mid-run?

A flow that starts with a webhook depends on the outside world, which makes it the flow type most likely to fail. A messaging provider stops responding, a field arrives unexpectedly empty, a downstream service goes offline for twenty minutes. What matters is not the absence of failure but whether failure is visible and recoverable.

Run History and Retry keeps a record of every execution and lets you retry failed runs in bulk rather than one at a time. After a half-hour outage on the provider's side, that is the difference between reopening forty runs by hand and recovering them in a single action. Half-finished runs do not pile up either: Stuck Run Cleanup detects and sweeps them, which is what keeps the history list worth looking at.

Retrying is not the right answer to every failure. A transient network error deserves another attempt; "this customer does not exist in the system" will not resolve itself no matter how many times you try, and someone has to look. Routing that second group to a human follows the pattern described in escalation that reaches the right person before the SLA breaks, and the same logic applies cleanly to technical failures.

How do you rehearse the flow before it goes live?

The insidious part of webhook flows is that the first real run doubles as the first test: a real customer, a real message, a send you cannot take back. The way out is to run the flow end to end against a sample payload.

Dry Run Testing exists for precisely this. It walks the flow step by step with sample data, shows which condition sends the run down which branch, and sends no real email, WhatsApp message, or SMS. Do not invent the test payload — use the example from the provider's documentation, or better, a capture of a genuine request. The small differences between the two are usually the whole problem.

Keep the door open after launch, too. Every save is stored as a version, so a flow you have broken can be rolled back with one click, and the state before the rollback is kept as well — you will not lose the only working copy while trying to repair it. That safety net is what determines whether anyone dares touch a live flow at all.

Will customers feel it when a burst of webhooks lands?

External systems work in batches. An overnight billing run, a bulk import, or a queue draining after an outage on the provider's side all mean hundreds of requests within a few minutes. A flow that obeys every request faithfully will send one person three messages in a row, or drop forty tasks into a single rep's queue at once.

Rate and Business-Hours Limits smooth that out: you set an execution ceiling per hour, day, or week, define a per-contact limit, add a wait between steps, and hold sends outside working hours until morning. A payment failure that lands at 3:40 a.m. enters the CRM immediately, while the message to the customer waits for nine o'clock. The same windowing logic decides what hour reminders are allowed to go out.

There is also the stop-on-reply behaviour: when a contact responds or the lead is closed, pending steps are cancelled. How automated sequences are balanced with brakes like these is set out in personalising at scale with triggered flows. In webhook-driven flows the brakes matter even more, because you do not control the volume of the trigger.

Where should automation stop and call a person?

As a webhook setup matures, flows get longer, and at some point a request from outside starts triggering a step with real consequences: suspending an account, marking a contract cancelled, initiating a refund. Those steps do not need to be automatic. They need to be fast.

The Approval Step halts the flow before a risky action, notifies the person you nominate, and does not let the run continue unapproved when the window expires. The information reaches the CRM in seconds; the decision stays with a human. The criteria for where to draw that line are argued in deciding where automation should stop. On the webhook side the working rule is simple: put a person in front of every step you cannot undo.

To keep the setup honest, open Automatic Diagnostics regularly. A disconnected step, a flow that has never once triggered, or an unconnected channel are all silent faults — nobody complains, because nobody notices the thing that was supposed to happen. A webhook flow with zero executions almost always means the endpoint was pasted into the wrong field on the sender's side.

If you want to try wiring an event from your own external system into a flow, create a Rocketly account and define your first endpoint in a few minutes.

FAQ

Who creates the webhook endpoint — do I need a developer?

The endpoint is generated on the CRM side while you build the flow; choosing webhook among the Multiple Triggers options hands you the address. Technical help is usually needed on the other side instead, since which event type maps to that address and where the signing secret goes depend on the provider's own console.

What if the sending system does not support signatures?

There are two partial compensations. Put a hard-to-guess component in the endpoint address, and require the payload to be consistent with a record that already exists in the CRM. Neither fully replaces a signature, which is why it is wiser not to attach irreversible steps to unsigned sources.

Can one webhook trigger more than one workflow?

It can, but the recommended shape is a single entry flow that calls sub-workflows. Three independent flows on one endpoint make it impossible to reason about what ran in which order; a single entry point evaluates the condition once and hands the work to the right sub-workflow.

What happens if the event belongs to someone with no record in the CRM?

Decide this up front. Two answers are defensible: create the missing record from the payload and continue, or stop the flow and open a review task. The wrong third answer is letting the run end silently, because that event will not come back and nobody will notice the gap.