Welcome back. So at this point, you understand most of the intermediate concepts within Bento, and I want to walk you through some different ways to build and test advanced flow logic and branching logic within. So in this video, we're going to go through three different ways that you can branch subscribers within different pathways in flows. And I'll have you basically just build them along with me so that you can play with them and understand them and use them yourself later.

So in all of these examples, what we are doing is testing a situation where somebody can buy either a pro plan from you or a lite plan. And so what these are simulating are a real-world event that would look something like this, where it would fire the purchase event with a plan type passed through. So the plan type in this case would either be professional or lite. And what we're doing with all of these, this little segment at the top, these nodes here, all of these ones, these are all just for our testing purposes.

So for a real-life actual execution when someone purchases something, none of those would be present. It would only be from here down for all of them. These ones at the top allow us to simulate a purchase of a pro plan and simulate a purchase of a lite plan. So let me show you how that simulation works.

First, they all work the same way, all three pathways for the top. So what we do with all of these is we have a callable event type, so in this case, test pathway one pro, or in this case, test pathway one lite. And the only real role that these triggers play is to give us something to trigger over in the run flow thing. So if you go manually add user, you can choose one of these.

And that's important because what they do downstream, they all connect to a create event node that passes the plan type that corresponds. So they all just simulate a purchase happening without you having to actually go purchase it yourself to trigger it. One important note with how Bento does event matching by default is that whenever you trigger an event, it does a contains match. So what I had originally done is the real chain would be called-- so in your case, not example purchase, it would just be your actual purchase.

So let's say plan purchase. If you were to go up here and you were to do test_plan_purchase, what would happen is when test_plan_purchase gets fired, that would also trigger this, because test_plan_purchase also contains plan_purchase. So in other words, this one I had Bento training example purchase one. Originally, I had this as test Bento training example purchase one, and that was causing this one to trigger, and it was a good reminder to be careful about that.

If you want to not do contains matching, and maybe Jesse will update this UI because he updates this to improve it all the time, and this one just rolled out a few days ago. So if you ever wanted to get around this contains matching, you can always use a liquid filter to do an exact match. And so in this case, the example here you could use. So if this one was, I think it's event.name, maybe.

Let's see if it auto-completes it. Hmm. I don't know. I would have to check the documentation.

I'm sure we can find it in the doc somewhere. But basically, you could have done it here. You could clear this out and have it exclusively living in the advanced filter to do an exact match, or just do what I did and very intentionally rename the longer tail one to not include the shorter tail one. So this one is Bento training example purchase one.

And so I did this Bento training test professional example purchase one, so now the words are in a different order. But yeah, in any case, the core flow of all these test things is that basically this test-p-whatever-whatever plan is just a really lightweight shell that we can call from the tester, and its only job is to fire an event with a specific plan type. So that's how all those work. And then, as I said, from the main trigger node down is what simulates and mirrors real-life functionality.

So let's look at the three pathways. So I would say for 90% of normal usage, [clears throat] magic splits are the way to go. What's especially nice with magic splits is that Tanuki can flesh them out for you really easily. Let me go find what I generated this one on the left with.

So ignore the ugly Obsidian notes, but this here is literally what I typed. "Create me a magic split where if event.details.planType is professional, it splits to the true path, otherwise splits to the false path." That's literally what I put into Tanuki to generate this, and that resulted in this. Obviously, this isn't such crazy liquid that maybe I could've just typed it my own self, but why type when you could have AI do it? And so in this case, what's happening is that we would just basically have this really deep true-false branching chain.

So if they are professional, it goes to the left. If they're not, then we check if they're lite, it goes to the left. This model is really useful when there are not that many possibilities something can be. Where it gets cumbersome is let's say you run an e-com and you have 50 products, or let's say it's for me with my Evergreen newsletter, where I have 50 different newsletters.

Having this deep chain of 50 if else's is really inefficient. If you imagine product number 50, newsletter number 50, it has to do 49 false cases before it hits true. And so if you're working with something like that, that's where pathway two and three, or pathway two or three will make a bit more sense. And in the case of 50 products, I think pathway three is the winner, because pathway two is this field switch, which I don't think it would even support 50.

And if it did, how the hell would you even control 50 little dots? So I'm sure he limits it to, I don't know how many, but I'm sure he limits it to something. So before we talk about those other pathways, though, let's do a little test on this first one. And actually, before we do a test, I should show you what you need to see in order to build it.

So let's first have you build the first one. So what we'll do for building this, I personally like this convention that I use of using comments throughout to self-document my flows so that future Zach doesn't have to remember what the hell past Zach was thinking when he put different nodes here. This isn't so important for this pathway one, where it's a relatively simple one, but for something like this, we're clearing out temporary fields, setting fields, that kind of thing, and it's important to remind future you why you did all this stuff. So let's first set up the core test pathways.

You're going to create three versions of this, and probably will have you create the new event and the tests. So what I want you to leave what we're about to do right now with is this. All of this stuff set up. And so I'll walk you through all those.

And notice how much I have them spaced out here. You don't have to do the little divider boxes, but if you want to, you can. Just right-click and go annotations and then box, and then you can just drag it to be skinny and wide. You can always resize this stuff later.

If you hold Shift and then left-click and drag, that's how you do this box. So if you ever need to do that, you can just move things around that way. So first thing to do, let's create the three real chain triggers. So you'll right-click and you'll go Triggers and go New Event, and you'll create it like this.

And I'm going to go somewhat fast in that I'm going to have you pause. So each time I tell you a step to do, I would just say pause the video and then go do the steps so that you don't get lost, and I also don't have to sit here in silence for 30 seconds per step. So first thing, create a trigger node. The trigger should be bento underscore.

Let's see if I can zoom in to make it easier. Come on, Mac zoom. Come on, Mac zoom. Okay.

Mac zoom is not working. Bento_training_example_purchase_1. That's the trigger event name. Nothing else to do here.

Save it. And then actually, maybe before you saved it, right-click and copy that label. And then you are going to create two more. But this time, instead of it being bento_training_example_purchase_1, you would create one called example purchase2, example purchase3.

So same name, just a different number at the end. And then at this point, you will have this, this, and this. You'll have your first trigger, like your real-life trigger node for each. Then the next thing to do is scaffold out the testing infrastructure.

So for each of those three trigger nodes, we want two test initiators, one for pro, one for lite. So in terms of batching, let's think of what's going to be easiest. Let's do the triggers first, I think. So with this one, remembering that advice I gave you a few minutes ago that we need to not have the real trigger as a substring of this test event trigger, I would recommend you just name it like I did here.

So bento_training_test_plan type__example_purchase_1. So basically, within the scope of one plan type, the thing that would change is the label of either professional or lite, and then the number changes based on the plan type. So these two here would have the number one, these two here have the number two, these two here have the number three. So I'll just click through to show you.

So Bento training test professional example purchase1, Bento training test lite example purchase1, Bento training test professional example purchase2, et cetera. The double underscore thing doesn't matter. I just personally like to do that to separate just chunks of data, but you do you. And then importantly, for these ones, to make them easier to select in the runner, I would recommend you change their field, or sorry, event node labels too.

So I did test-pathwayX, so pathway1, pathway2, pathway3, and then -plan name. And this will make it really nifty when you're in the little Run tab because you can just so easily pick them. Whereas if you hadn't changed that, it would be that really long-form name that would probably overflow the box on my screen. So create those six, so all of the test initiators, and then we're going to create the six event firers.

And so these ones are all quite simple. Basically, the two events within a pathway, they will both fire the same event name that you set below. So in this case, Bento training example purchase1 is what both of these fire. Bento training example purchase1.

And if you're in here, you can literally just right-click this and it'll select the whole text. You can copy it. And then this, the thing to understand is that these up here were new event triggers. So you went right-click, Triggers, New Event.

But these here are create event actions. So you right-click Actions, Create Event. And then you paste that event type, and then the difference within each is the plan type. So the one that's connected to the pro chain should pass plan_type of Professional with a capital P, just because that's a convention we've been using so far.

In general, I would try not to use capital letters if I could avoid it, but alas, that's what we've been doing the whole training, so that's what we're doing here. And then the other one, still firing purchase1, but this time for lite And so do that for all of them. And so in other words, this one is Bento training example purchase three, plan type light. And then connect them.

So you want the event trigger to connect to the event action, trigger to the action, and these are going to connect to nothing. So when an event that you create connects to nothing, it's the equivalent of if you went in here and you did... Where is it? Split in logic, end session.

So something connecting to nothing is the equivalent of connecting it to an end session. In this flow, I only actually use the end session node when I need it. So for example, when you split plan type as professional, if I didn't have an end session node on the left, so the true line didn't connect anything, the simulator might not run it or it might not show which way it evaluated because it doesn't go anywhere. The simulator highlights things green.

So in cases like this where you want to simulate something, it's important that you have that mark as complete just for showing you what happened. But purely from a flow execution standpoint, it doesn't need to be connected at all because it doesn't. [chuckles] If somebody ends a node and flows off into the abyss, that's the same as if you ended the session. So at this point, you should have all your little test spoofers created. And for any complex automation chain you ever make where you plan to test it for a lot of different potential values, I think this testing infrastructure we created up here is really useful, just like spoofing events.

You can also do this manually, but where it gets hard is passing event parameters, because I think when you're on a user's profile and you manually fire an event, I don't think-- You can't actually pass a parameter here. So the only way you could manually create an event for testing purposes would be, gosh, I guess if instead of this event looking at the plan type from the event details as the thing dictating our chain. So for example, down here, event.details.plantype. Instead of that, if it worked more like this one, which we'll talk about later, where we actually include the plan type in the event name, then you could get away with not having all this because you could go to a user's profile and literally fire that event name.

So what you'll learn in a minute is that this is for pathway three, literally the event name, and there are no parameters passed because they aren't needed. Because the only thing we really need is the name of the thing. So I do this for my lead magnets, for example. It's like lead magnet opt-in__lead magnet name or whatever.

And I use that because in the case of lead magnets, there are fixed details that every lead magnet would have, like the user's first name and stuff, which actually, that doesn't even need to be event param because that comes through as a custom field. So all I really need to know when I'm sending someone a lead magnet is just the name of it. And I'll show you this in one of the example videos in the next section. So I'm not going to worry about that here.

But in any case, for something like this where you're spoofing event details, I just want you to know this testing infrastructure that we're doing here is a pattern that I use quite a lot and that you can use quite a lot. So it's not just for this one video, it's for real life, too. Wow. So [sighs] with all that stuff done, you should be able to build this first pathway now.

So again, you can just have Tanuki do it, or you can do it yourself. Basically, magic splits. So if you go right-click, split in logic, magic split. They're really, really useful for a couple of reasons.

Number one, they're powerful because you can do any Liquid evaluation within it. And then number two, what I like best about them is they evaluate basically instantly. So if you do a split in logic that is a normal split, it basically goes into the Bento event queue where Jesse processes every single thing that happens in a node, every single email that goes out. All of these things have to dispatch an event in his code.

And when you do a magic split, it doesn't do that maybe or something. I don't really know how Jesse's code works, but all I know for sure [chuckles] is that a normal split has a delay, a magic split does not, and that's nifty for us. So as a rule, doing only magic splits is best. So any split Tanuki ever makes will be magic splits.

So if you just want to ask Tanuki for something and review what Tanuki makes, that's great. Or you can just type it yourself since it has auto-complete. The main thing that's important is that the word true or the word false needs to be output. So just make sure that whatever you do here, it's always going to result in one of those, because one of those needs to-- One/both need to happen for it to actually branch successfully.

So in other words, if only true ever gets output, I don't know what'll happen in the else case. I haven't tested it. Will it default to false if the word false isn't present? I don't know.

We could test it. And actually, maybe I will test it. So I'm going to show you how to test your flow. And I'm meanwhile going to test what happens if I intentionally break this to be bad.

So let's say I changed it to this. So now it either outputs true or it outputs nothing at all. So don't you do this. This is bad.

Bad Zach. I'm just wondering, because I'm going to show you the testing SOP. So basically, the testing SOP from here-- Oop, I just meant to save that. You first want to flesh out both magic splits and connect them all to just mark session complete.

So that's under somewhere. I don't remember where. Attributes? No.

Splits in logic, end session. End flow is something else. End flow is for ending a different flow. We don't want that.

We just want end session. That's ending this current session, and we need that for the simulation. So create your magic split for the pro plan, create your magic split for the light plan, hook all the true and false cases up to end sessions other than this first one. So basically, what happens here is we say, are they professional?

If yes, mark complete. If no, are they light? If yes, mark complete. If no, also mark complete.

But this here is technically an error case. So in real life, nobody should ever hit that. And if they do, you'd probably want to know about it. And so in that case, you could do something like, I think, yeah, Bento has a send internal email, for example.

So you could send an email to yourself that's like, "Yo, there was a bug in your automation. You should probably go fix it," to catch these kind of edge cases. So let's save it, and let's test it. So what we'll do is we'll go to the Run panel, and for this one, what do I want to check?

I personally am going to do Lite because I want to see if false evaluates when it was missing. That's what I'm testing. So we'll go manual add user, and then I'm personally going to do test P1 Lite. You can do Pro or Lite, doesn't really matter.

Just remember which one you did, because you'll do the other one in a moment. I'm going to click Start Session. So we see it's queued, and I'll close it. And now we want to wait for this test user to show up, which they did.

So now what we can do is we can go to their profile with this little Open Profile thingy, and we can look at their event log, which is the first panel. So see how this first one, example purchase one, happened just now? We can click this little clipboard icon to copy that event, which we can use for the little simulator view back in the flow. So now if we go into Run, we can click this What Will Match thing, paste the event ID, click Run Test, and it'll give us this really nice highlighted flow that the user took.

And in this case, look at that. My little janky test to see if false can evaluate simply by the absence of something, it proved that it is true. So provisionally, at least for now, the only thing that's actually important is for it to output true when true, and that presumably, like anything else, will just result in false. That's my guess, but this is breaking the official docs, I think.

Oh, no, it doesn't, because see this right here? I should have just read the freaking page. They go to the true path if it says true, otherwise down the false path. So false is just a fallback.

So good to know, but probably still smart to be explicit and not rely on that false path. So I'll probably take this, put it back. Just good habits. So this simulation of what will match is really useful for cases like this, where everything's simple and self-contained.

But for Pathways two and three, we actually can't really use it, unfortunately. Because what this one relies on is user profile data and event data. And in both of these cases, we can't stream that quite as well. We can do it here, for example, but this creates different event chains, so you wouldn't be able to see it connect all the way down.

You can only see the details of the specific chain it matched, and that'll make more sense in a second when we talk about it. So before we move on to Paths two and three, just make sure you've tested this and also run it on the other. So I just did it on Lite. Do another on Pro now and make sure that it doesn't do this and that it instead does this.

So we'd want it to go boop, boop, and then to the left path. And if something about this doesn't work correctly, talk to Tanuki until you get it working correctly, because it's really important that you understand how to debug these things, test these things, and make sure they work as expected. And any comments you want to leave for yourself about how different things work, why they work, why you built them the way they did, the way you did, I think that's a good habit to build. So maybe take a moment to leave some of those comment notes.

My personal convention is that I use purple, so I'll go in here, click it in the color picker. I use purple for titles of flows, and then blue for little annotations, and then I reserve yellow and red for bugs or to-dos or something like that. But you do you. So now let's talk about Pathway two.

The core job to be done of all three pathways in this example is the exact same. So all we're trying to do in Pathway two is, again, just do some special stuff for the Pro plan people, do some special stuff for the Lite plan people. So in reality, maybe you'd send a special email like, "Welcome to the Lite plan," versus, "Welcome to the Pro plan." And that's what all three of these chains accomplish. But the difference of the how is what differentiates them.

So in this case, at the time of recording, so July 2026, when you are using a field switch, so you right click, go Splits and Logic, go Field Switch. This field switch is nifty from the standpoint of being able to branch out for, let's say you have five different plans. If you're over here for five different plans, you'd have to create five if else's, and so that was the example I gave before. For a match on number five, it has to first evaluate four, which for five plans I don't think is a big deal, but as it gets to be a larger number, like 10, 20, 50, maybe it is a big deal.

Or maybe you just like the idea of doing it this way. And in this case, what we do is we run that switch, but it has to be on a custom field. It cannot be on event details. So I would say if you're in real life working with a situation like this, you probably should never do Pathway two.

I was actually thinking of deleting Pathway two from this video, but I figured I would still show you because I think the workarounds that I put in place teach you some really interesting core concepts about Bento that I use all the time when I butt into situations like this that I think would be good for you to learn. So we'll do Pathway two, but just understand you probably shouldn't actually do Pathway two. You'll either do Pathway one or Pathway three in this exact situation, which is to say the plan name is passed through event details, so it's not available as a custom field. That's like the je ne sais quoi of why we're not going to use Pathway two.

But all that being said, let's take a peek at how it works, and you can follow along too. So let me give you the high level first. So the first high level is that the field switch is the key piece here However, because at the time of recording, the field switch cannot evaluate Liquid, that means that we can't say, "If event.details.planType equals professional, go here. If it equals light, go here." We can't, because I tried that, and it evaluated to the fallback, which meant that it wasn't actually parsing it.

And so because of that, we have to use this strategy that I use sometimes, which I would call temporary field value stashing. So whenever there's something that can't parse event details, but that you need to be able to parse event details, what you can do is you can create a temporary field that you plan to clean up and delete in a moment, where you stash that info. So this case, I just made a field called TMP__ and again, the double underscore doesn't matter, it's just a taste thing, planType. And then I pass event.details.planType, and then the field switch is not looking at the event details, it's looking at that custom field we stashed.

Does that make sense? Hope so. And one other consideration here is that the nice little what will match dry run thing that we did over here where it made all these green, this relies on real-time information about the user and the event details. And so in this case, because the field switch is looking at their temporary field, and because we delete that temporary field immediately after setting it, we cannot use the dry run what will match.

You can, but it'll be wrong. So if you use the dry run what will match, it'll always show you the error pathway even when it didn't happen. And the reason why is that let's say you click initiate and it flows through right now, right this moment. And you wait a minute for it to show up on the right side, and you go to the profile, you copy the event ID, you paste it into the what will match.

By then, it's fully run, and it's fully deleted this. And so given that this is matching on the value of temporary plan type, and given that when you click what will match, temporary plan type is empty, it'll always show you this fallback. And so that's where we use one more temporary field, which is almost this debug output field. So I created this.

So TMP route to path professional. So basically, this is here as a logger to let future us know this is the pathway that was taken, and that lives on their profile. So basically, the way that this would work in practice is that the test stuff, it fires exactly the same as always, and then it hits the new event node exactly the same as always, nothing special. And then we clear out the path that got hit, so that every time we run this, we have fresh data.

Because let's say that you didn't clear it out and it was set at professional for the previous run, and then this time, I don't know, something happened where it didn't set it to any value at all, it would still show professional making you think it hit professional when actually it didn't hit anything at all. In the case of this flow, that's literally not possible because this pathway, we literally set it to other. But nonetheless, I think it's good practice to clear out debug test fields before logging to them. So that's what we do.

We clear that out before we start. And then as I already showed you, we just set the plan type to event.details.planType, and then we fill out the field switch for our two plan options. Notice that we have capital B and capital L. That's important because that's what we set them to up here.

So it needs to exactly match to evaluate true. And then once it does match successfully, we clear out that plan type because it's not needed anymore. And that's my rule for temporary fields, is I try to clean them out if I can. In this case, we leave it uncleaned because we need to look at it as debug data.

But for something like this where we're literally just setting it so that we can read it, I do like to unset it immediately. And then we make that log entry just for debugging purposes, and then you would send whatever email, et cetera. So now you know that strategy. Again, I don't think you need to do this for real life, but I did want to teach you this concept of temporary value stashing.

So in this case, you're good to run it again in the tester. So you go Run, Manually Add User, test.p2, and let's do light this time so I can show you the value changing. And click Start Session. And I guess I can show you this one matching incorrectly too.

So if I go to their profile, it'll take a couple minutes to evaluate through. Like you see, this still shows professional, but it's also still running at the time of refresh. See how it's still running this flow, so it's not totally done yet. And if I refresh again, and so now it shows light.

Cool. And it'll probably show it as being complete. Oh, but it still says running three out of four steps. So we'll give it a minute before it's complete, but that's an important thing when you're testing this stuff is don't expect it to be instant.

And you can use the flow status of running or completed to help you determine if your stuff is broken or if maybe it just hasn't gotten to that step quite yet. So in this case, it's showing five out of six steps. Seven out of seven. Cool.

So now it's done. And so if it still didn't show light, that would be concerning. And now to show you what I mean about evaluating incorrectly. So if we look at this flow, the only possible situation where it could evaluate or it could get set to light is this middle one, right?

Because this sets professional, this sets light, this sets other. So there's literally no other way The word light could get set as the value for a temporary route two path. But with that in mind, if we go to run, we go to what will match, and we paste that event ID. Wow, look at that.

So if we were relying on this, we would think we broke our thing and that it didn't work. But alas, this is just that thing I said earlier where it's looking at current data. And so in this case, this node is looking at temporary plan type, but this person doesn't have temporary plan type, and that's why it would evaluate false. So we have to rely on some way of logging on their profile or otherwise, that XYZ thing happened.

All right. So now let's look at the final pathway. This is a pattern I use quite a lot. In my production Bento, this pathway too, I pretty much never use it.

I don't think I've ever used a field switch even one time. I didn't even really know it existed until the other day. But what we're about to do, I use all the time. I mentioned earlier the lead magnet context.

So this one's quite simple, but it can be harder to simulate. So I would say still don't use it over the magic split unless you've got a really good reason. So, the 20 products e-commerce thing is a good example. My shadow newsletter, Evergreen Newsletter, is a good example.

Lead magnet's a good example. But basically, the way it works is that this one fires as normal, so test purchase three with event.details.plantype. And then we change the name of the event we call to inject the unique identifier, assuming it's a normal word with no spaces. I think if it was pro space plan, I don't think this would work.

You would probably need to do some liquid to transform it, because I don't think event names can or should have spaces. So that's one consideration for you. But when I do this for my lead magnets, for example, I'm passing the lead magnet slug. So if the lead magnet's called free training course, it would be lowercase free_training_course.

That would be what's getting passed here. And so what this does is we call an event that is a modulated name based on the plan name. So in this case, we're either calling one called purchase_Professional with a capital P or purchase_Light with a capital L. And so all this does is we just set these up where we have that name thingy at the end, and then that's it.

Simple. And you can see here in the event log an example of it being called, and you can see an example of it being called authentic at all when I originally did a typo here. So originally, I created this with plan_name, and then I ran it, and I was like, "What the hell? Why didn't it run?

Oh my God, Bento's so broken." And then I checked, and up here I saw that it was plan type, and I had typed plan name. So that's the debugging process. And this is another instance where the what will match won't work. So let's have you build it out first.

So basically, [inhales] whatever your two plan names are from up here, so Professional, Light, you need to create two event triggers down here with a predictable pattern at the beginning that's the same between both. And then the only thing that changes is the plan name. So that's what these two triggers are, and then that's it. And if you needed to, you could change this with liquid.

Let me test something real quick. So I'm going to, again, test some weird stuff. I don't know if it'll work. Two things I checked is how with Liquid we could lowercase something, and I see-- I just Google this stuff.

So Liquid lowercase, you could ask Tanuki, you could ask the GPT I linked to, whatever. But these were simple enough, I figured I would just check. And in both of these cases, it looks like there are ways we can handle these situations in real life. So [inhales] let's think of how I can show you.

Okay, so here's what it would be IRL. So the first thing I had up, the white space control, did not work correctly, which makes sense. I'd never seen it before, and what I was trying to find anyway was just a replace. So Liquid, as you probably know from the Liquid lesson if I said it, [clears throat] Liquid allows you to append these little pipes followed by different liquid functions to change things.

So in this case, if we had this string, it would just output pro plan. So pretend this was your event.details.planname was pro space plan. That's what I'm simulating up here. It would output it exactly as is.

But if we append downcase, it will change it to be lowercase pro space lowercase plan, like this. And then we can append this find and replace where it'll replace spaces with underscores and do this. So if you were ever trying to do this for realsies, let's take these. And you could, if you're using underscore and lowercase anyway, it would be pretty safe to just do this from the start.

So if you want to do some advanced stuff right now, instead of just doing event.details.plantype, try this. So space downcase or space pipe space downcase, then space pipe space replace a space with an underscore. Let's see if I can zoom on this. No, I can't.

Maybe I can zoom on the liquid tester field page. Yeah, there we go. So basically, you just want to append this to what you have, or technically append this with a space. And if you do this, the difference for your flow, in my case, it'll be almost the same, but the event names will be different.

They'll be lowercase, which is better practice anyway. So I would go in here and change this. So I'll just copy, delete it, and change it to lowercase professional, and then I'll do that here too. And then let's do another one.

Maybe I'll just change this to be a little bit more interesting. So let's say this one, instead of light, I'll just do an example, like example multi-word light. Save that, and then I'll need to change this. And you don't have to do this part, I just want to show you.

Example multi. Ooh, and let's actually do this. Let's keep the hyphen so you can see what I mean. Multi-word light.

So in reality, you would've hyphenated this. You would've said multi-word. But because we only replaced spaces, it wouldn't have replaced that hyphen. So if my theory's correct, if I save this and I go run, manually add user, P3 light, we should see an event name fired for them that matches this.

And in this case, as I mentioned before, we can't really test this one with the dry run matcher either. We rely on looking at their event log. So this case, don't see it quite yet, but these things do take time sometimes. Let's see if the flow's still running.

Yeah, so we see it's still running, so that's potentially fine. Doesn't necessarily mean I messed up. Ooh, yeah. Look at that.

And so we can do the simulator for the pathway that gets called from the main event. So in other words, let me show you. So when you run the simulator for these, you either get to simulate just these or just these. You don't get to simulate all four.

And so in this case, if I wanted to, I could copy this and go into the little what will match dry run thing and choose that event. And it does show these two. It's just not that useful, in my opinion, for something simple like this, because what we would really want to see is that it hit these two and then it hit these two, but you can't see that because they're two different event chains. So one event chain was this one.

So if I copy that, we can go here, and now you see these, and then the second event chain was these. So the only way you can know that they ran in sequence like this is just by looking at the distance when they were called and looking at the flow history and stuff like that, seeing that these all chain together. So hopefully this was useful for you. In general, as I said before, sticking to something simple like the magic splits is what you'll want to do most of the time, but the underlying concepts that allow these two others to work are really useful advanced concepts for you building more complex email automations.

So hopefully you got some nice gems here, and see you in the next video.