Bento

Misc Flow Tips & Performance Optimizations

Speed up your flows with magic splits, use global ENVs, time triggers, and inbound webhooks.

You've built flows with events, sequences, tags, fields, and emails.

Now let's cover a handful of flow features and performance tips that didn't fit neatly into the earlier lessons but are worth knowing as your automations get more complex.

Each of these is something I wish I'd known earlier.

None of them are required to use Bento effectively, but they'll save you time and make your flows faster and more maintainable.

Always Use Magic Splits

In the How To Use Liquid In Bento For Epic Power lesson, we covered magic splits - Liquid-based conditions that evaluate to true or false.

Here's the performance reason to always reach for them:

Standard if/then splits add roughly a 5-minute processing delay.

That matters when you need something to happen quickly - like routing a subscriber immediately after a purchase event, or sending a time-sensitive confirmation.

Magic splits process nearly instantly.

Beyond speed, Tanuki defaults to magic splits when it scaffolds flows for you.

So if you're using Tanuki to build your automations, you're already getting magic splits by default.

Jesse's take on standard splits: "Old split is dead to me. VIVA LA MAGIC SPLIT."

The recommendation: Use magic splits for everything, even simple evaluations.

There's no reason to reach for the old standard split anymore.

The syntax is simple (you learned it in the Liquid lesson), the performance is better, and the AI tools already prefer them.

Liquid Filters on Event Triggers

When you create an event trigger in a flow, the basic configuration lets you match events by word - you type keywords and choose a matching mode ("All words" or "Any words").

That works for most cases, but it has a limitation: it matches by contains, not equals.

If you have two events called user_preference_wants_abc and missing_user_preference_wants_abc, a trigger set to "All words" matching user_preference_wants_abc will fire on both events - because the longer event name contains all those words too.

For situations like this, there's an Advanced: Liquid filter option below the basic matching config.

It works on the same principle as magic splits: you write a Liquid expression that outputs true or false, and the trigger only fires when it evaluates to true.

The filter gives you access to three variable families:

  • event.details.x - any field from the event's detail payload
  • event.type - the event name itself
  • visitor.x - subscriber fields

So for the substring collision example above, you could write a filter that checks event.type for an exact match instead of relying on the word-based matcher.

The Liquid filter also comes with preset buttons for common patterns - things like "Cancel at period end," "Amount > value," "Status equals," and "Plan contains" - so you don't have to write the Liquid from scratch for the most typical use cases.

If you set both the basic word matching and a Liquid filter, they stack - the trigger has to pass both checks before it fires.

Time Triggers & Custom Field Delays

In the Events & Flows Overview lesson, we covered basic delays: wait a fixed amount of time, wait until a specific time of day.

There's a more powerful option: delay until a date stored on a subscriber's custom field.

This lets you build automations relative to each individual subscriber's timeline, not a fixed calendar date.

Examples:

  • Trial expiration: Set a trial_ends_at field when someone signs up. Build a flow that delays until that date, then sends a "your trial is ending" email.
  • Onboarding milestones: Set created_at when they join. Delay 30 days, then check their engagement and route accordingly.
  • Renewal reminders: Store subscription_renewal_date and trigger a reminder flow 7 days before.

The key insight: instead of trying to calculate "wait 30 days from when they entered the flow," you store the target date on their profile and tell the flow to wait until that date arrives.

This is especially useful when the timing depends on something that happened outside of the flow - like a signup date set by your app, or a purchase date from Stripe.

Global Environment Variables (ENVs)

ENVs are site-level variables you set once and reference anywhere in your emails and flows using Liquid:

{{ ENV.VARIABLE_NAME }}

(We touched on these briefly in the Liquid lesson.)

Here's why they're so useful in practice.

The problem ENVs solve: You have a value that shows up in multiple emails or flows, and when it changes, you don't want to hunt down every place it's hardcoded.

Common use cases:

  • Business address - required in email footers for CAN-SPAM compliance. Put it in an ENV; update it once if you move.
  • Current promo details - "20% off with code SUMMER20" showing up across multiple flows and broadcasts. When the promo ends, update the ENV instead of editing 15 emails.
  • Spots remaining - "Only 12 spots left" in a launch sequence. Update the ENV as spots fill; every email using it reflects the current number.
  • Support links / URLs - if your help desk URL changes, one ENV update fixes every email.

Think of ENVs as global constants for your email marketing.

Anything you catch yourself copy-pasting into multiple emails is probably a candidate for an ENV.

Inbound Webhooks

This is a newer Bento feature worth knowing about at a high level.

Normally, to get data from an external tool into a Bento flow, you'd route it through middleware like n8n, Zapier, or Make - receiving the webhook there, transforming the data, then firing a Bento event via the API.

Inbound webhooks let you skip the middleware entirely.

Here's how it works:

  1. In the flow builder, add an Inbound Webhook trigger
  2. Bento generates a unique URL for that trigger
  3. Point your external tool's webhook at that URL
  4. When data arrives, Bento catches it, parses it, and starts the flow

If the person doesn't exist in Bento yet, the inbound webhook creates them automatically.

Example: You use Calendly for scheduling sales calls.

Instead of Calendly → Zapier → Bento API, you point Calendly's webhook directly at your Bento flow's inbound webhook URL.

The flow fires immediately when someone books a call - no middleware, no extra steps.

This won't replace a full automation platform if you need complex data transformations between systems.

But for simple "something happened in Tool X, trigger a flow in Bento" use cases, it removes an entire layer of complexity.

Injecting Test Triggers Mid-Chain

In the Advanced Flow Branching lesson, you built test triggers at the top of a flow to fire the entire chain with spoofed event details.

But sometimes you don't want to test the whole chain.

Maybe you want to test just a delay node deep in a flow, or verify that a specific branch works correctly without running through 10 upstream steps first.

The technique: drop a temporary Event Received trigger partway down the chain, right before the segment you want to test.

Give it a distinctive event name - something like test_debug_delay_section - fire that event on a test subscriber, and watch just that part of the flow run.

Once you've confirmed the section works, remove the temporary trigger.

That wraps up the intermediate section.

You now have the toolkit for building sophisticated Bento automations: AI-assisted email creation, event-driven flows, behavior-based triggers, Liquid templating, bulk operations, and the performance tips from this lesson.

Next up: the Real Life Use Case Examples section, where you'll see complete, working Bento setups in action - from lead magnet delivery to evergreen newsletters to AI-orchestrated weekly broadcasts.

You already have the concepts down; the examples section shows you what's possible when you combine everything you've learned.