Branch Node

1. Purpose & When to Use

• Decision Logic: Use Branch Nodes whenever the conversation must diverge based on a variable, user answer, or action result.

• Zero AI Output: Branch Nodes do not generate text. They simply route the flow.

Branch Nodes are the backbone of decision-making in your flow. Use them to route conversations based on user input, variables, or action results—keeping your logic clean, modular, and easy to debug.

• Multiple Conditions: If you have more than two possible directions (e.g., “Low,” “Medium,” “High” risk), you can configure as many outgoing nodes as needed, each mapped to its own set of criteria.

• Keep Flows Understandable: Resist the temptation to place complex logic inside a Step Node or a Conversation Node. If you’re checking “if user said X” or “if <apiCall.value> > 10,” put that in a Branch Node. This way, the AI-facing nodes stay focused on content, and the Branch Node stays laser-focused on routing.

---

2. Branch Node Fields & Configuration

1. Branch Name

   • What It Is: A concise, human-readable label that describes the decision point—e.g., “Is Email Valid?” or “Loan Amount Bracket.”

   • How to Choose:

     1. Clearly state the question or condition being evaluated.

     2. Avoid generic names like “Branch 1” or “Decision.” Instead, name it after the key variable or outcome you’re checking (e.g., “User Opt-In?”).

       2.  Condition Type

Toggle between two modes:

c. Deterministic Rule Settings

(Visible when you select “Deterministic Rule”)

• When Variable

• Operator: Select from 

  • Equals to = 

  • Not Equel to !=

  • Contains

  • Starts With

  • Ends with

  • Less than <

  • Greater than 

• Target Value: Enter the literal or set to compare against (e.g. Yes, [“admin”,“superuser”], 1000).

Click Add condition to chain multiple variable tests. Branches are evaluated top to bottom.

2. Branch Name Name each outgoing edge exactly as the LLM should pick it.

3. When to Go Here

   • What It Is: A free-form, plain-language (or pseudo‐code) description of the condition under which this branch should be taken.

   • Syntax & Guidelines:

     1. Reference Variables & Action Results by wrapping them in {} for variables and <action.field> for action outputs.

     2. Precision Over Prose: Write the exact logical test. E.g. If the user said Yes

   • Multiple Outgoing Nodes: Each node from the Branch Node inherits its condition from “When to Go Here.” You assign a unique condition per node. The engine evaluates them in the order you list them; the first matching condition “wins.”

---

3. How Transitions Happen

1. Evaluation Moment

   • The flow engine pauses at the Branch Node after the previous node completes—whether that was a user response in a Conversation Node, a Custom Action in an Instruction Node, or a Function Node updating data.

   • Immediately, it evaluates each outgoing node’s condition in sequence.

2. Matching & Routing

   • First‐Match Wins: The engine checks Node 1’s condition first. If it’s true, the flow goes down Node 1. If not, it checks Node 2, and so on.

     1. You can also select in the Deterministic Rule that All Rues Must Be True, if you want to branch based on multiple conditions/variables

   • Fallback Node (“Else” or “Default”): Best practice is to include a final, catch‐all node with condition true—this avoids runtime errors if none of your prior conditions match. Label it clearly (e.g., “Default Path”).

3. No AI or User Interaction

   • Branch Nodes are invisible to end‐users. There’s no prompt or pause for a user reply—unless a later node explicitly asks. The Branch Node only does logical evaluation, then immediately hands off to the next node.

---

4. Best Practices & Tips

1. Keep Conditions Atomic

   • Don’t cram five checks into one condition. If you’re checking both “age > 18” and “has ID on file,” consider chaining two Branch Nodes or splitting logic across them. Keeping each condition simple makes debugging infinitely easier.

2. Order Your Nodes Strategically

   • Place the most likely (or most specific) conditions first. For example, if 80% of users are in the “US,” put {country} == “US” as Node 1. Otherwise, you’ll hit that catch‐all too early.

3. Always Include a Default/Fallback

   • If none of your conditions match at runtime, the AI might hallucinate and say something you didn’t plan for. Save yourself the headache: add a final node with condition true or else → so that there’s always a path forward.

4. Reuse Variables & Action Results Consistently

   • If two different Branch Nodes rely on the same data , make sure that data comes from a single Step or Function Node upstream. Don’t recalculate or redefine variables in multiple places—consolidate.

5. Don’t Use Branch Nodes for Simple “Wait for User Input”

   • If all you need is to wait for user text or a button click, use a Conversation or Step Node with a prompt. Branch Nodes should not generate output; they should only evaluate logic.

---

5. Common Pitfalls & How to Avoid Them

1. Missing Fallback

   • Symptom: For some inputs, none of the node conditions match → runtime error: “No valid outgoing branch.”

   • Solution: Always include a final node with true or else as its condition. Name it clearly (for debugging) and send the flow to either a “retry” or “error” node.

2. Over‐Complex, Nested Logic

   • Symptom: A single Branch Node’s “When to go here” is a 100‐word boolean expression with nested parentheses. Hard to read, debug, or modify.

   • Solution: Break complex logic into multiple Branch Nodes chained in series. For example:

     1. Branch A checks {age} >= 18. If yes, go to Branch B. Else, go to “Minor” path.

     2. Branch B checks {credit_SDEre} >= 700. If yes, go to “Prime Rate” path. Else, go to “Subprime Rate.”

---

9. Summary & Takeaways

1. Branch Nodes do not speak or execute API calls—they only evaluate conditions and route the flow to the correct next node.

2. Keep conditions simple, ordered, and mutually exclusive wherever possible.

3. Always include a fallback node (condition true) to avoid “no valid path” runtime errors.

4. Name your Branch Node clearly so that anyone scanning your flow instantly grasps the decision logic.

5. If your logic grows complex, break it into multiple Branch Nodes in series rather than stuffing everything into one giant branch

---

Quick Checklist:

• Every branch has a clear, descriptive name
• All conditions are simple and atomic
• Fallback/default branch is present
• No output or user prompts in Branch Nodes
• Branch order matches your flow’s logic