Routing

A routing setup decides what happens to a lead after it arrives. It holds your rules, the destinations those rules point at, and any conversion or CRM events that should fire afterwards.

It is not owned by a form. It is a library object, and many forms can point at the same one. Set it up once, attach every campaign to it, and change the destination order in a single place when a destination's payout changes.

The library

Routing lists everything you have, with how many branches and destinations each one holds and how many forms are attached to it.

The switch on each row is Live or Paused. A paused routing setup still receives leads - they are captured, normalised and stored - but nothing is routed and nothing is sold. It is the right control for taking routing offline without dismantling it.

A routing setup cannot be deleted while a form still points at it. Detach the forms first; the error names them so you know where to look.

The canvas

Open a routing setup and you get a canvas with three fixed columns.

Left is the routing setup itself - its name, whether it is live, and which forms feed it.

Middle is one node per branch, each showing the preset it uses and a numbered badge telling you the order it is tried in.

Right is that branch's waterfall - the destinations it offers the lead to, stacked in the order they will be called.

Pinned at the bottom is the default branch, drawn with a dashed line. It catches everything no preset matched.

You cannot draw connections by hand, and you cannot connect things that should not connect. The canvas is a picture of your routing, not a place to invent new shapes - the layout is derived from the configuration, so a branch always looks like a branch.

Branches

A branch is one preset paired with an ordered list of destinations. That is the whole idea.

Add one with the Add branch button, or by dragging a destination from the palette onto empty canvas - Formwork will ask which preset it belongs to, because a destination on its own is not a branch.

You can pick an existing preset or create one right there. A preset created this way belongs to just this routing setup; one switch promotes it to the global library if you later want to reuse it.

Order is priority

Branches are tried top to bottom, and the first match wins. Drag a branch up the middle column to give it precedence. Nothing below a matching branch is ever considered.

The numbered badge on each node is the live answer to "which of these gets asked first" - it is not a field you set, it is where the node sits.

Order inside a waterfall

Within a branch, drag destination chips to change who gets first refusal. The lead is offered to each in turn, and the first whose response passes its accept rule wins it - everything below is never called.

You can also drag destinations straight from the palette onto an existing waterfall to append them.

Attaching forms

The Forms tab in the inspector lists every source feeding this routing setup.

This is also where Formwork checks the field contract. A routing setup knows which canonical fields it needs - every key referenced by its presets, its destinations' body templates, its ping templates and its event payloads. Each attached source is compared against that list, and anything missing is flagged per row.

Take those warnings seriously. A preset testing a field that never arrives does not error - it simply never matches, which quietly sends every lead to your default waterfall.

Attaching happens from the form's side too: pick a routing setup in the create wizard, or change it later from the form's settings page.

Events

The Events tab configures what fires after the waterfall settles. Unlike the rest of the canvas, it is a draft with a Save button, and it applies to the whole routing setup rather than to one branch.

There are two lanes, and each has a trigger: fire when the lead sold, when it was declined by everyone, or always.

Conversion reports the outcome back to an ad platform so its optimisation has something to learn from. Meta Conversions API is the supported provider: give it your dataset or pixel ID, an access token, an event name - Purchase by default - and optionally send the sale price as the event value.

Personal details in a conversion event are SHA-256 hashed before they leave, as Meta requires. You do not have to do anything to make that happen.

CRM pushes the outcome somewhere of your own. Either a plain webhook, where you control the endpoint, the headers and the body template, or Meta's CRM postback. A CRM body can reference {{system.stage}}, {{system.price}} and - usefully - {{response.anything}}, which reaches into the reply the accepting destination gave you.

Checking and testing before you go live

Two more inspector tabs earn their place.

Checks lists everything wrong with the routing setup as configured - a branch pointing at a deleted preset, a waterfall with no destinations in it, a destination that no longer exists.

Test runs a sample lead through the routing without sending anything, so you can see which branch it would match before a real lead finds out for you.

When both look right, press Activate.

Overriding a destination for one routing setup

Destinations are shared, so editing one in the directory changes it everywhere. When a single routing setup needs to send something different - an extra field, a different campaign ID - select that destination on the canvas and override only what differs.

Everything you do not override keeps following the directory entry, so a destination that changes its endpoint is still a one-line fix. The destination's name, whether it is enabled, and its delivery mode always come from the directory and cannot be overridden here.

What to read next

• Fields - the vocabulary presets and destination templates are written in.
• Presets - the rules a branch is built on.
• Destinations - what a waterfall is made of, and what counts as an acceptance.