Welcome back. In this lesson, I'm going to give you a bit of a primer on how events and flows work in Bento. And then in the coming lessons, we'll actually be doing some more of the take action style stuff where we build things. But for now, I just want to give you an overview, because this concept, especially of events, is not always intuitive if you're coming from a platform like ConvertKit, or I guess they're just Kit now, [clears throat] where pretty much everything there is tag driven.

Someone got a tag, you removed a tag, et cetera. And it can sometimes take a moment to adjust to the concept of events, but once you do, there are a lot more possibilities that events bring, and it's one of Bento's coolest things, even if it's maybe not intuitive because it's not common in the simpler platforms or whatever. I don't know. In any case, within Bento, everything that ever happens is initiated by an event.

And the event is the thing that happened. And sometimes an event might be somebody had a tag added or a tag removed, or other times the event might be somebody purchased a product in Shopify. Other times it might be a user did blah blah blah thing inside of our app, or other times it might be it's Thursday at 9:00 a.m., which is a cron event trigger. There are a bunch of different shapes that an event takes, but the thing that they all have in common within the context of Bento is that they all follow the Bento events structure.

So if you click the link to the Bento events page in the docs, you can see how the events are structured. Basically, any event coming into Bento needs to have the event type, so the name of the event, the email address of the person it's happening to, and then these two really powerful objects as they're called in JavaScript. But basically these, let's think how to say it in normal words. Sets of data?

Is that how we could say it for a non-developer? Basically, you can pass as many or as few things as you want within the event details, and same deal with fields. The difference between details and fields are that the event details are used within an email automation flow for understanding what happened and doing things based on that. So in this case, the value of the purchase was 99 US dollars, and the thing purchased was the annual subscription.

So the automated flow can look at the event details and branch accordingly. So if somebody bought an annual subscription, send them this email. If they bought a monthly subscription, send them this email, or add this tag to them, or wait five minutes and then call them, or whatever. Bento doesn't call them, but it could tell you to call them.

Whereas fields, anything you pass here will actually get set as a custom field value on the subscriber. So the way that I like to differentiate them is that event details are ephemeral data that only exist for the flow that's understanding it, and it's used to do other stuff with. Whereas fields are when you literally want something to persist on the person's profile. So if you look at a lot of these, most of these wouldn't make sense as fields.

If you said product ID on John Doe's profile, that's confusing. John Doe is not a product ID. And even if you change that to product ID purchased, that's confusing too, because what if John Doe buys another product later? So you wouldn't want to shove these things onto a profile.

Most of the time, what you would maybe do is put these things into your workflow. The workflow looks at what product they purchased, and maybe it puts a tag on John where it's like, "Purchased this product." So that later when they purchase five others, he now has five tags of different products he's purchased. So we're going to get into flows later, and this one I have is somewhat complex. But I wanted to show you this as an example of how events can be branched based on.

So in this case, when we fire an event called, in this case, it's a test example plan, professional plan purchase. When we fire that event and that event contains an event.details for the plan name, it can either be professional or light. We can then in our workflow split based on that. So we can say, "Is the plan that was purchased professional?

If so, go down this route. If not, go down this route." And then down here, we can say, "Okay, well, it wasn't professional. Was it maybe light? If so, go down this route.

If not, go down this route." And with this kind of branching, we can do some really powerful stuff, which is really exciting. And if all this looks intimidating, it doesn't have to be that intimidating, because one of the cool things about Tanuki in Bento is that Tanuki can actually help you scaffold out flows. So, like this kind of branching here, I think Tanuki might have even made these in the first place. It would make these little magic splits for you and stuff.

But alas, don't get overwhelmed yet. We're going to play with these more, and we're going to onboard you with much simpler flow than what you see here. This is from the very last lesson in the section. With regards to events, what's useful about Bento is that if you click to a user's profile, you just look them up in the People tab and you click into them.

By default, you're going to see recent events that have fired for this person. And if you click into one, you can see all the info that came along with it. So you can see that in this case, the event details was only set to have a plan type, and this was the value for it. So plan type was example multi-word light.

That was the value that came through. The event type was Bento training example purchase three. So this is a really useful way to get a sense for what's coming ... through from your external tool if it's integrated with Shopify or whatever, and also help you build your automations to just see how this stuff's structured. So you can even copy the Liquid, and so now it's event.details.planType because that's what corresponds here.

So this view is really helpful because you can essentially just copy and paste from here into your workflow. One other thing I also wanted to note for you is that event names, so in this case, this event name/event type. I call it event name, but I think it's formally called an event type. So this and this, they're the same thing.

They can start with a dollar sign if you want. They could start without a dollar sign if you want. All of the internal Bento events, like somebody viewing a page on your site, which is this, someone clicking a link, somebody unsubscribing, et cetera, they all have dollar signs. And Jesse likes to do this format where he'll namespace things with a dot.

For me, I tend to not use the dollar sign for my events. It's just a pure taste thing. So I just wanted to flag that for you. It doesn't actually affect how anything runs.

So to give you a bit more of a primer on the flow side of things, basically a flow is pretty much broken into triggers and actions. So something happens to trigger the flow, that's a trigger. And then actions are a myriad of options of things we could do. So I have them all on the page.

Or not all, but many of them on the page that are the most common. But I would say that the most common thing I would see in a flow or that I use in a flow is a trigger, which is typically an event or a tag, and then usually a delay, let's say a five-minute delay or a one-day delay or something. And then an action, which is usually sending an email. Or in the case of that complex flow, we didn't actually build any actions, so never mind.

But you might do one where based on what product they purchase, you add a tag to them so that you can always look them up based on products they've purchased before. Those would be actions. And then conditions and splits are what we see here. So any of these things where it can branch both ways, that's what's called a conditional or a split.

One of the things that's really cool about Bento is that you can actually trigger additional events from one flow chain. So I think I have that in here. Yeah. So in this case, we did something crazy, which is that this here is an event trigger, and it contains, just like the other branch I showed you earlier, it contains the plan that was purchased, so either the pro plan or the lite plan.

And then this here is an event action. So this triggers based on one event, and then this here fires a different event. But what's really cool is that when you fire a different event, you can actually pass in the trigger's event details into the action. So in other words, the trigger one up here, the top one, received the event.details.planType.

And then right here, we're running an action where we're actually injecting that plan type into the name of the event we're calling. But we could also have done it here. So you could do thing one, and you could literally not do all that other stuff to make it simpler. You could do this.

So now you'd be firing a new event with these event details, and in this case, the wild stuff we're doing is we're actually changing the name. So in this case, what's happening is it's either going to fire an event called Bento Training Example Plan Purchase Professional or Bento Training Example Plan Purchase Lite, because those are the two possible things that could come through as the plan type. And then these right here are new event triggers looking for those specific things being fired. So lots of really, really powerful stuff you can do when you have an event that gets triggered, you do some stuff based on the information, and you fire off other events.

You can build very powerful automations this way. And similarly, you can do creative delays this way. So instead of your delays always being wait one hour, wait one week, whatever, you can also have your delays wait until something that was passed in from an event or something that's set on a user's field, which is quite cool. I don't want to overwhelm you, though, any more than I already have.

This will become a lot more intuitive as we go deeper and have more practice. So the final thing I want to talk about in terms of the functionality within the Bento flow editor is the splits. So there are actually two splits. So if you right-click anywhere, you can open up the quick drop menu, and within Splits and Logic, you'll see Split and Magic Split.

Magic Split is relatively new, and it's the one I showed you before. The old split is pure UI. So, you choose the thing, you choose the values, et cetera. It's a bit more intuitive to build yourself, but the Magic Split has a couple of advantages.

So number one, the Magic Split processes almost instantly, whereas the normal split adds about a five-minute delay for each one, just due to the way Bento in the back end processes different events in the queue and stuff like that. So what this means is if you do something like a thanks for ordering email, adding a five-plus minute delay to that is not ideal. And so having a Magic Split before that first email gets sent is really important if you want the person to receive their thank you email as quickly as possible. And then the other advantage or consideration is that whenever you have Tanuki help you with a flow, it will be building Magic Splits.

But you do you when you're building these. We'll get more practice with the Magic Splits as we go, and it's perfectly fine to use the regular split when you're just getting started if the Magic Split feels overwhelming So one little note for you with regards to building your flows out. At the top right here, there's this draft versus live status. So basically, when it's in draft mode, none of the emails will get sent, and I don't think even the triggers will fire.

So the draft mode is good for when you're first fleshing stuff out, and you don't want events to accidentally get called. But from the moment where you're ready to start properly testing it, you'll want to switch it to live mode. And to me, the main milestone for me deciding if I switch from draft to live in my own flows is, will this flow accidentally get triggered for a real user? So if you have a trigger event that's maybe something really generic, like let's say subscribe as your trigger event, that's risky to switch into live mode because if a new user subscribes while you're playing with this, they will get whatever work in progress stuff you have.

So if you're building something for that, what I would usually do, let's say that you are literally doing one for subscribe. So let me find it real quick. Okay, so let's say you do a custom event and... Oh, let's actually not do a custom event.

Let's just do the default here, and you do subscribe. And then let's say that you're going to send an email. Let's say this is your flow that you want, which probably this would be not a good idea. You shouldn't build this flow because a lot of people will get emails who you wouldn't want, but pretend it was.

What I would personally do if I were doing this, and we'll talk more about this later, I would create another trigger that's my debug mode trigger that would be called something like test whatever. And I would temporarily disconnect the subscribe one, and I would make a little note that's like, "Zach, to-do, reconnect this when done." I do this all the time. And so what this will mean is that you can safely publish this because all the new subscribers hitting the subscribe event, they're just having nothing happen. Something like this where it ends with nothing at all is the equivalent of if we did-- Where is it?

I have to find the... There's one for ending the flow. Here we go. End session.

So nothing at all after a card is the exact same as this mark complete one. And so in this case, it would allow us to have this in live mode, which is important from a testing perspective, and also not worry about normal users hitting it. So we could just fire this event for our testing user and make sure everything's solid, and then once it is, then we can just connect this, and it should all work. But alas, I don't want any of this.

So let's delete that. Save it. I have some notes in here on how to use Tanuki. It's just over here on the left-hand side.

You can ask it for whatever you like. I don't personally ever use Tanuki in flows, and we won't be doing it much in this training. But it's still useful if you're struggling with a blank page, and it can scaffold out some of the stuff for you. A few other things I wanted to just flag as a preview.

You can have some flows cancel other flows. So a moment ago when you saw me going into the splits and logic, and I did end session, there's this other one called end flow. And with this one, you can actually choose a different flow to cancel all sessions for the current user of. Where you would use this is imagine someone's in some sort of abandoned cart sequence, or more specifically, an abandoned cart flow.

So instead of building a proper sequence, you did it here in a flow where you literally had a delay, and you say, "Wait two days." If you had this, and somebody bought during that two days, and let's say that flow is called abandoned cart flow. And then you're over here in the product purchase flow. You can, from the product purchase flow, choose the abandoned cart flow in the end flow, and you can actually kill that abandoned cart once they purchase, which is really useful. So instead of them waiting the rest of those two days, it'll just cancel it.

So that's a nifty thing. And then I already mentioned this one. You can pass event data further down from chained events. We went through that.

We talked about the dynamic event name. So I think you've got a pretty clear map. And in the coming lessons, it'll be a lot more clear and comfortable as we do some practice and simple builds and ease into more complex stuff. So let's keep it going, and I'll see you in the next lesson.