In the previous lesson, you learned how Liquid works in Bento.
Now you're going to build and test three different flow branching strategies, all solving the same job: routing a subscriber based on their plan type.
The video walks you through building each one step by step.
This page covers the core concepts, key gotchas, and reference info you'll need while following along and afterward.
For reference, see the Workflows, Liquid Template Guide, and How to Test Email Flows docs.
Which Strategy to Use When
All three pathways in the video accomplish the same thing: branching a subscriber into different paths based on incoming data.
The difference is how.
Magic Splits (Pathway 1): Use these 90% of the time. They evaluate nearly instantly, Tanuki can scaffold them for you, and the Liquid syntax is straightforward. Best for a small-to-moderate number of branches.
Field Switch (Pathway 2): A visual, point-and-click branching UI. Looks clean, but it can't read event details directly - you have to stash the value on a temporary field first. In practice, you'll almost never need this over a magic split. I teach it here because the workaround pattern (temporary field value stashing) is a useful concept you'll encounter in other contexts.
Event Name Dispatching (Pathway 3): Dynamically constructs the fired event name using Liquid, so different downstream triggers catch different events. Best for high-cardinality scenarios - 50 products, many lead magnets, an evergreen newsletter library. Each variant gets its own discrete flow chain without needing a million magic splits.
Key Notes From The Video:
Event Naming: The "Contains-Matching" Gotcha
Bento matches event triggers using "contains" logic by default, not exact matching.
This means if you have a trigger listening for bento_training_example_purchase_1 and you fire an event called test_bento_training_example_purchase_1, both triggers will fire it!!! - because the longer name contains the shorter one as a substring.
This bit me while building this flow template initially.
The fix: rearrange the naming so the test prefix breaks the substring match.
Instead of test_bento_training_example_purchase_1, use bento_training_test_professional__example_purchase_1.
Now the words are in a different order and the shorter name is no longer a substring of the longer one.
If you ever need exact matching instead of contains, you can use the Advanced: Liquid filter option on the event trigger config. Write a Liquid expression that checks event.type for an exact match, and it'll only fire when the expression evaluates to true.
Rule of thumb: whenever you create test event names alongside production event names, check that neither contains the other as a substring.
The Test Trigger Infrastructure
For each of the three pathways, you'll build two test triggers - one that simulates a "Professional" purchase and one that simulates a "Lite" purchase.
That's six test triggers total.
Each test trigger is a lightweight two-node chain:
- Event Received trigger (e.g.,
bento_training_test_professional__example_purchase_1) - Create Event action that fires the pathway's real trigger event (e.g.,
bento_training_example_purchase_1) withplan_typeset to eitherProfessionalorLite
The test triggers exist so you can fire them from the Run panel and have the real chain execute with specific event details.
This matters because you can't pass event parameters when manually firing events from a subscriber's profile - the profile UI only lets you fire the event name, with no way to attach details.
Label each test trigger clearly - something like "Test P1 - Pro" and "Test P1 - Lite" - so they're easy to pick from the runner dropdown.
This pattern isn't just for this exercise.
Any time you build event-driven flows that depend on specific event details, this test trigger infrastructure is how you'll test them reliably.
Documenting Your Flows With Comments
Before building the pathways, a quick habit worth forming: use comment annotations to document your flows.
Right-click the canvas, go to Annotations > Note, and add a comment next to any node that deserves an explanation.
A color convention that I personally like:
- Purple for section titles and pathway headers
- Blue for annotations explaining what a node does or why it's there
- Yellow / Red for bugs, TODOs, or things that need attention
This matters most in complex flows where future-you won't remember why past-you built something a certain way.
Pathways From The Video
Pathway 1: Magic Splits
Magic splits are chained Liquid conditions that evaluate to true or false.
The chain here is simple: the main trigger catches the event, a magic split checks "Is plan_type Professional?" - if true, done. If false, a second magic split checks "Is plan_type Lite?" - if true, done. If false, that's a fallback/error case.
Each terminal path connects to an End Session node.
Without it, the simulator won't highlight which path was taken - the green highlighting needs somewhere to land.
You can have Tanuki scaffold these for you. An example prompt:
Create me a magic split where if event.details.plan_type is "Professional" it splits to the true path, otherwise, splits to the false path
Then follow up: "looks good, now please another for if the plan type is 'Lite.'"
Performance note
This is the key reason I recommend you almost always use magic splits over standard splits:
Standard splits add roughly a 5-minute processing delay per split. If you have 10 options in a chain, the 10th one won't even be evaluated for almost an hour.
Whereas magic splits evaluate nearly instantly.
Jesse's take: "Old split is dead to me. VIVA LA MAGIC SPLIT."
Testing Pathway 1
This is the one pathway where Bento's built-in simulator works reliably.
- Open the Run panel
- Click Manually add user
- Select your test trigger (e.g., "Test P1 - Lite")
- Click Start Session, then close the Run panel
- Wait for the user to appear in the logs sidebar, then click their profile
- On their profile, find the event in their event log and click the clipboard icon to copy the event UUID
- Back in the flow, open the Run panel again
- Switch to the What will match dry-run mode
- Paste the event UUID
- Click Run test - the flow highlights the path taken in green
Run both Pro and Lite to confirm each branch works as expected.
If something doesn't route correctly, double-check your nodes and/or talk to Tanuki until you get it working.
Debugging these things yourself is an important skill to build.
Pathway 2: Field Switch (Temporary Value Stashing)
A heads-up before you build this one: you probably shouldn't use a field switch for this scenario in production.
The field switch can't read event details and can't evaluate Liquid, so it requires a workaround that adds complexity.
I teach it here because the workaround pattern - temporary field value stashing - is a useful concept you'll encounter when other Bento features can't access the data you need.
How it works
The Field Switch node can only branch based on a subscriber's custom field value.
It can't look at event.details, at least at the time of recording.
The workaround:
- Stash the event detail value on a temporary field:
tmp__plan_type = {{ event.details.plan_type }} - Switch on that field - the field switch reads
tmp__plan_typeand branches to Professional, Lite, or Other (Fallback) - Clean up - clear
tmp__plan_typeon each branch after routing. Don't leave stale temporary data on subscriber profiles.
The tmp__ prefix (double underscore) is just a naming convention, not a Bento requirement.
It signals "this field is temporary and should be cleaned up."
Matching is case-sensitive: "Professional" with a capital P must match exactly what the field switch expects.
The debug output field
Because the dry run simulator doesn't work for this pathway (explained below), you need another way to verify which path was taken.
So we add a debug output field - something like tmp__route_2_path - and set it to "Professional," "Lite," or "OTHER" on each branch.
Clear this debug field at the start of each run, before the field switch.
That way stale data from a previous test won't confuse you.
Why the dry run simulator fails here
Bento's "What will match" simulator relies on current subscriber data to evaluate the flow.
The problem: by the time you copy the event UUID and paste it into the simulator, the flow has already finished running and the temporary field has already been cleared.
So the simulator sees an empty tmp__plan_type, evaluates the field switch against that empty value, and always shows the "Other" fallback path.
This doesn't mean your flow is broken - the simulator just can't replay the transient state.
Check tmp__route_2_path on the subscriber's profile instead.
Pathway 3: Custom Event Name Dispatching
This one dynamically constructs the event name that gets fired, so each variant enters a completely separate downstream chain.
How it works
- The main trigger catches the incoming event (with
plan_typein the details) - A Create Event action fires a new event whose name is built with Liquid - the base name plus the plan type appended
- Two separate Event Received triggers downstream - one listening for the Professional variant, one for the Lite variant - each with their own chain
The result: each plan type enters a completely discrete flow chain, with no if/else branching at all.
Liquid for safe event names
Event names shouldn't have spaces.
If your plan names might include spaces or mixed case, use Liquid filters to normalize:
{{ event.details.plan_type | downcase | replace: " ", "_" }}
This converts "Pro Plan" to pro_plan, which is safe to use as part of an event name.
When this approach shines
Magic splits work great for 2-5 options.
But for high-cardinality scenarios - 50 products, dozens of lead magnets, an evergreen newsletter library - chaining 50 if/else magic splits gets unwieldy.
Event name dispatching handles this cleanly: one dispatch node, N downstream triggers, no cascading evaluation chain.
Testing Pathway 3
The simulator shows individual event chains, not cross-chain sequences.
You can simulate the dispatch chain (main trigger > Create Event) or an individual downstream chain (e.g., the Professional variant), but you can't see the full sequence in one view.
The most reliable approach: check the subscriber's event log on their profile.
You'll see the dispatched event name and the downstream trigger it matched, with timestamps showing the sequence.
If the wrong event name shows up, check for typos in the Liquid expression - that's usually the issue.
When to move on
- You've built and tested all three branching pathways
- You can explain when you'd reach for magic splits vs. event name dispatching
- You understand the contains-matching gotcha and how to name test events safely
- You can set up test trigger infrastructure for any event-driven flow
- You've used the simulator and understand its limitations per pathway type
- You've added comment annotations to document your flow