Route to a sink
Routing decides which sinks a source's messages reach. It lives on the Flow page: sources on the left, the Center in the middle, sinks on the right.
Broadcast is the starting state
With no routes configured, every source delivers to every active sink in the project. Flow says so explicitly — "Broadcasting to all sinks".
That is a convenience for getting started, not a configuration. It means adding a second sink silently starts sending it everything, including data it has no business receiving.
Wire a pair
Open Flow → Routing, then connect a source to a sink.
As soon as one route exists, the project switches to explicit routing: sources deliver only to the sinks they are wired to. Flow's banner changes to confirm it.
Each pair is independent. One source can feed three sinks; one sink can receive from four sources; each of those pairs carries its own output structure.
One pair, one shape
This is the part people underuse. Because the output structure is set per pair, the same message can arrive as a full envelope in your archive and three bare fields in your billing system — with no duplicate routing and no transformation on your side.
See Choose what the sink receives.
Removing a route
Disconnecting a pair stops delivery between them. Both integrations stay exactly as they were — a route is the wire, not the endpoints.
Remove the last route in a project and it falls back to broadcasting to all active sinks. Worth remembering before deleting what looks like a redundant route.
Deciding the shape of your flow
A few patterns, and when each is right:
| Pattern | Looks like | When |
|---|---|---|
| One to one | source → sink | A single deployment feeding a single system. |
| Fan out | source → several sinks | Same data to billing, archive and a dashboard, each in its own shape. |
| Fan in | several sources → sink | Sigfox and LoRaWAN meters into one platform. Normalisation means the sink cannot tell them apart. |
| Split by rule | source → sink A or sink B | Alerts to one place, routine readings to another. Needs a rule. |
Fan-in is the one worth calling out: because messages are normalised before routing, a sink receiving from two different device networks gets one consistent shape. That is most of the value of the Center in a single diagram.
Preview before you commit
The Routing dialog previews what the selected sink will receive, rendered by the same code that performs delivery — with your decoder's field names and last-seen values, not a sample fixture.
Use it. It is much faster than saving, sending an uplink, and reading your receiver's logs.