Support branching and nested logic across all flows/routers
E
Earl Laing
Routers currently only support linear rule evaluation, where every path is built sequentially at the same level. For organizations with complex routing logic, this means building a flat list of highly specific paths, for example 60 separate SDR paths instead of one parent path that branches into sub-paths. There is no way to group related logic, nest conditions, or build branching flows that check one criterion before evaluating the next.
Routers should support branching logic and nested rule structures, allowing admins to define a primary condition such as market segment or language, then evaluate secondary conditions such as territory under each branch, rather than enumerating every possible combination as a flat path.
As organizations scale and routing logic grows more complex, linear routers become unmanageable. Branching and nesting would reduce path sprawl, make routing logic easier to audit and explain to new team members, and allow routing configurations to scale with the business without becoming brittle.
Taylor Jennings
Merged in a post:
Configure branching paths after form submission based on responses
Taylor Jennings
After a form is submitted, all leads follow the same path regardless of how they answered. There is no way to create different downstream experiences based on specific form responses.
Admins should be able to configure branching logic that routes leads down different paths after form submission based on their responses, enabling differentiated experiences without multiple separate forms.
A single post-submission path forces teams to either oversimplify their routing or create redundant forms. Branching logic unlocks more precise qualification and routing without added complexity.
Taylor Jennings
Merged in a post:
Concierge: two ownership paths
M
Meenal Gupta
We have AEs and BDR team, that track ownership in separate fields. The ideal concierge flow would be: If a prospect books a meeting --> check AE ownership else round robin within AE team. If a prospect does not book a meeting --> check BDR ownership and then round-robin within BDR team.
Currently, I need to setup an elaborate work-around to update a field --> trigger distro --> check BDR ownership, which is not ideal.
Taylor Jennings
Merged in a post:
Handle Multiple CRM Object Match Types Within a Single Distro Router
L
Lex Levitte
When a lead comes in and matches to different CRM objects, such as an existing lead, a contact, or a contact with an account, each match type requires its own separate Distro router to take different actions. There's no way to handle lead-to-lead, lead-to-contact, and contact scenarios with branching logic inside a single router.
Admins should be able to configure conditional branches within a single Distro router based on what type of CRM record the incoming lead matches, eliminating the need to build and maintain multiple routers for the same lead flow.
D
Dana Lee
+1 to this comment. I have so many distro routers because I can't have another decision node after the first one. The complexity around trying to remember which routers needs to be updated for one small change is going to be limiting.
A
Angela Welch
This would be an absolutely critical update for us at Jobber. The current limitations are very frustrating to build a whole new set of rules and branches for every tiny biforcation in the process.
Like do x y z and then evaluate another criteria if A do that path and if B do the other path. Right now, it's so build intensive and this is how other routing tools work
A
Angela Welch
This would be an absolutely critical update for us at Jobber. The current limitations are very frustrating to build a whole new set of rules and branches for every tiny biforcation in the process.
Like do x y z and then evaluate another criteria if A do that path and if B do the other path. Right now, it's so build intensive and this is how other routing tools work