What it is.
A Data Table stores the last route used. A Code node increments the counter and cycles it back to the start, and a Switch node sends the execution down the matching path.
The routes arrive as placeholder nodes you replace with your own sub-workflow calls or API triggers. Merge logic preserves the original input, so whatever triggered it survives the routing step.
What you get.
- A persistent counter in a Data Table, so the rotation continues after a restart.
- A Switch-based router with placeholder routes you swap for your own.
- Merge logic that keeps the triggering data intact through the routing step.
- A pattern that works with any trigger type, including a webhook or a schedule.
How to set it up.
Create the Data Table with the last-used field before importing, since every run reads it.
Set the cycle length in the Code node to match your number of reps or destinations.
Replace each placeholder route with a sub-workflow call or an API request to your CRM.
Check the merge step keeps your lead payload, because a router that loses the record is worse than none.
Trigger it a dozen times by hand and confirm the rotation is even before it touches a live lead.
Add a fallback route for the case where the Data Table read fails.
Use cases
Rotate leads across a team
Keep the counter in a Data Table so the rotation survives a restart.
Add a rep without a rebuild
Extend the router with the placeholder branches already wired.
Prove the split is even
Read the counter when someone claims they get fewer leads.
Best for
Even lead assignment
Rotating inbound demos across reps without buying a routing product.
Rate-limited destinations
Spreading calls across several accounts or API keys so no single one gets throttled.
Any workflow needing a memory
The persistent-counter pattern is reusable well beyond lead routing.