Who can use this feature?
This article explains in more detail about the Routing Rule node in Orchestrator, and how to set it up, ensuring your Flows stay consistent with the routing logic you already trust in Chili Piper.
Table of Contents
- What Is the Routing Rule Node?
- Why Use It Instead of a Condition?
- How to Use It
- What It Can Read
- Condition vs. Routing Rule
What Is the Routing Rule Node?
The Routing Rule node reuses an existing Chili Piper Routing Rule to split the Flow into a true path and a false path.
For example, a rule already exists that flags Enterprise accounts in Salesforce for routing. Dropping a Routing Rule node and pointing it at that same rule lets the Flow branch on its result, without rebuilding the logic from scratch.
Why Use It Instead of a Condition?
One source of truth. If the same "is this Enterprise?" logic lives in five Flows as five separate Conditions, that is, five places to fix when the definition changes.
As a Routing Rule, the logic is updated once, and every Flow that references it stays in sync. When the logic is shared and important, that consistency is the whole point.
How to Use It
Add the node where the Flow should split, then pick the rule in the Rule Picker. This creates a true path and a false path, and each path is built out with whatever should happen on it.
What It Can Read
The in-context rule editor works with Salesforce Lead, Contact, and Account. For it to work in Orchestrator, a Matching node with the objects the rule needs must run earlier in the Flow; otherwise, Orchestrator does not have access to that information.
Condition vs. Routing Rule
Worth repeating, since it is the common mix-up. A Condition is inline and local to this one Flow. A Routing Rule is saved logic reused across Flows. Pick the Routing Rule when the rule already exists and should stay consistent everywhere it is used.
Comments
0 comments
Please sign in to leave a comment.