Lead states across locations

Lead states used to be scoped to a single Lead Pool — “PT vereinbart” in Pool A was a different record than “PT vereinbart” in Pool B, so every multi-location flow that set a state needed a Router plus one “Leadstatus setzen” node per pool. That burden is gone.

After the global-lead-state cutover (June 2026), a lead state is one org-global record. Assign it to as many pools as you like (see Lead states); it’s still the same ID. So a single “Leadstatus setzen” node referencing that global state applies to leads in every pool that shares it — no router, no duplicate nodes.

The common case: one node, no branch

If all your locations move leads through the same state (e.g. every pool has “PT vereinbart” assigned), build one trigger → one “Leadstatus setzen” node:

[Trigger: Neuer Termin gebucht]
        |
[Leadstatus setzen: "PT vereinbart"]   ← the global state, shared by all pools

In the state picker the list is still grouped by pool for readability, so a shared state appears under each pool it’s assigned to — but every one of those entries points at the same global ID. Pick it from any group; the result is identical.

Assign the state to every pool the flow touches

Setting a global state on a lead whose pool doesn’t have that state assigned still works at the data level (the reference resolves), but the lead renders uncategorized on that pool’s board until you assign it. Map the state into each pool whose leads can reach the node.

When you still branch per pool

Branching is only needed when locations should land in genuinely different states — e.g. Location A uses “PT vereinbart” while Location B uses a distinct “Probetraining geplant”. Those are two different global states, so you route to the right one:

[Trigger: Neuer Termin gebucht]
        |
     [Router]
   /            \
Pool A          Pool B
  |               |
Set             Set
"PT vereinbart" "Probetraining geplant"

The Router’s edge conditions match on the pool the lead came from; each branch sets that location’s chosen state.

Filtering on table.name vs table.id

When you do write a Router edge condition, you can match on either:

Match on	Pros	Cons
table.id	Robust to renaming the pool	Less readable in the flow view
table.name contains "<location>"	Readable; survives if you rename the pool key	Breaks if the pool’s display name is edited

Use table.id. It’s slightly less readable but doesn’t quietly break when a customer renames a pool.

Consolidating divergent state names

If two locations diverged into near-duplicate states only because the old per-pool model forced separate records, you can now merge them into one global state (Lead-Pools → Konfiguration → Lead-Status → Status zusammenführen). After merging, the per-pool branch collapses into the single-node case above.

What’s next

• Customer-source picker — required on triggers like “appointment booked” to populate the variable list correctly.
• Snapshot semantics — the consequences of editing a flow mid-flight.