So in previous lessons, we covered some of the more basic usage of flows, where we essentially slotted somebody into a sequence and pulled them out of a sequence. In this lesson, we're going to get familiar with event details and custom fields on a visitor's profile for changing how our flow works and behaves. This lesson represents how I personally use flows the most and where I think they're most powerful and exciting, because it's not just this simple one-size-fits-all basic routing logic, it's actually personalized automation, and that's, to me, one of the things that's the most special about Bento, and it's what I like the most about it. I linked, as always, to the relevant docs in case there's anything you need to look up as we go.

So, an important thing for you to know, that's really useful, is that for flow emails, so not a sequence that you trigger from a flow, but a literal email inside of a flow, you can use both visitor data and event data. And event data is what's quite cool about a flow email. So, for example, let's say somebody purchases a product from your e-commerce store, and you have 1,000 products. It would be very cumbersome to create 1,000 different sequences, each of which just says, "Thanks for buying blah, blah, blah, specific product." Instead, you could have an email inside your flow that injects the product name that they purchased, and that's what this is doing here.

So it'd be like, "Hey, Zach, thanks for signing up for the professional plan." And so this here, the plan name is coming from the event details. But remember, event details store ephemeral data, data that will be lost the moment the flow has exited. And so in this case, if it was for a SaaS and you only have three plans, you probably wouldn't bother with this, and you would probably have specific welcome emails made for specific plans, because presumably, if somebody joins the enterprise plan versus the pro plan, they should receive different content substantially, versus just changing the plan name. But for our practice, this is what we'll do just to get you familiar with how this data personalization works.

Because this ability to personalize an email with event details, I don't think any of the other platforms besides Bento that I've used have allowed us to even do this, and I think it's a really powerful feature that's easy to overlook. So I want to force you not to overlook it. So what we'll do today is basically build one primary chain where when someone purchases, we will set a field and a tag based on what they bought and stuff. And then we'll send a personalized welcome email with data that comes from their profile and from the event.

And then we'll set up a little testing trigger side chain as well, so that you don't actually have to go make a test purchase in order to trigger this, and we can just click the little test button, which is a really useful aspect of testing flows that we haven't talked about yet. So you won't have to, this time, go to their profile and manually paste an event name. We'll be able to do it just from the flow builder. So, let's dive on in.

First thing we need to do is disable the flow from the previous lesson. So if you were in that one, you actually already saw me accidentally trigger this lesson's flow from that lesson, because I hadn't disabled them. So at this point, you should have no flows in live status, or at least none that might conflict with what we're doing. So just go into it, toggle from live to draft, click save.

And you'll only have to do that for one. I have to do it for two, because I've already made this flow that we're about to make, and I don't want to double trigger it. So at this point, if I go here, the only ones that are live are these, and I guess I also don't need this one. So, that's done.

I'll keep this one live. You shouldn't have that because we haven't talked about it yet. Then we will create a new flow called Bento Training Signup Data Flow. And I'm just going to call, for my purposes, V2, since I already have one in there, but you should not do that.

And then what we'll do is set up the event received trigger. So I'm going to delete the default again, just to get you in the habit. So delete that one, right click, triggers, new event, and then it'll just be $signedup. Lowercase signed, underscore, lowercase up.

So just that. Not signedup.free, just signedup. And one important note, which we learned in the other video, and the reason I had you disable that other flow, the other one was signedup.free. This is the literal event name.

And so what that means is that if that other flow fired off signedup.free, and we did this one with signed up as the trigger, the thing is, by default, it's doing a string contains match. So when somebody fires off signedup.free, that also contains signed up, and it would thereby fire this flow even though we probably didn't want it to. And that's something to be very careful about because it can result in unexpected stuff happening. So if you ever need to avoid that, we'll talk a bit more about Liquid later.

You could, in this case, literally, instead of saying contains, which is the default, you could do no filtering up here and you could do, down here, if event.name, or what is it? Type? Hold on. I have to find out.

Type. So I pulled up the event here. We see it here as type. So you could do something where if event.type == and then [clears throat] quote "signed up." You could do something like this and then have it say true Else, false, end if.

So this is what's called Liquid, and as I said, we'll talk more about it later. I don't want you to feel like you have to do this now. I just want you to know there is a way that you could work around this contains issue, which is by having a Liquid expression literally matching equals. So in this case, if what was passed in was signed_up.free, it would not equals it, and thus it would resolve to false, and thus you wouldn't get this thing accidentally firing for some other flow's event.

But the workaround if you don't want to mess with Liquid is to be a little bit more careful about your event names, and that's why Jesse does the namespacing, is that he would presumably never have something called signed up just by itself. He would always have signed up dot something. But for me, I have had flows that I accidentally trigger due to this substring matching before. So trying to have your triggers match on an exact equals versus the contains is a nice workaround, or using tags or whatever.

But tags, same deal. If there's a tag called purchased-product-something else, the purchased-product one, if you had another tag for just that, would still get triggered if the purchased-product-something else also got triggered. But this is a rabbit hole. It's not relevant for what we're doing now.

I just wanted to note that. So back to what we were actually doing. New event, triggered for $signed_up, and that's it. No free, nothing else.

And we should not have any Liquid here. Save. [clears throat] We'll keep it in draft for the moment because we don't have anything worth publishing yet. The first thing that we'll do is add a personalized email to it. So if we right-click, Action, Send Email.

We can, let's see. Yeah, you could have Shoji do it if you want, or you could just literally copy and paste what I have, I think would be simpler. I'm sorry, I meant to say Tanuki, not Shoji. I will just manually create a Shoji email myself with no Tanuki help.

So start from scratch. Edit content. And then we just copy in what I have here. Don't worry about this saying that the subject line is too long, because it has no idea what it'll be once it's resolved.

So if this was like, "Welcome to the Pro Plan, Zach," suddenly it's not too long. So that's fine. And then we can grab this body content and paste that in. And you can just leave that as is, honestly.

A couple notes about what we're seeing here. So again, this is all what's called Liquid, which we'll talk more about later for the variable injection. And with Liquid, these little pipes, like these tall pipe thingies, they're used for separating, almost like functions that Liquid has. And one of those functions is this default.

And so what it's saying is that if the visitor's first name exists, put that here. If it's empty, then we're going to default it to something else, so in this case, "there," and this case, "friend." So it would either say, "Hey, Zach," or, "Hey there." Up here, it would either say, "Welcome to the Pro Plan, Zach," or, "Welcome to the Pro Plan, friend." And importantly, because this one doesn't have a default, if for some reason the plan name wasn't passed through, it would literally say, "Welcome to the space space plan, friend." So that's a consideration, but in this case, we're going to be testing it, and I would think that this is a pretty highly controlled piece of data that I wouldn't personally bother to have a fallback for, because it should never not be this, especially if we have checks within our flow logic to say, if they're in one of these two plans, or if they're in this specific plan, send it such that by the time they receive it, we could know for sure that it was set properly. But for what we're doing today, that's not the case. So technically, if you were to fire this event without a plan name, the user would get that error-y subject line like this.

But it's just an example, so it doesn't matter that much. We'll save this, and then you can close that Editor tab, and you'll be back on your Flow tab. And if you were to click out of that email node and back in, you should see the stuff you set, subject line and body text. Next thing we want to do is set a field on their actual profile for the plan that they purchased.

So what we'll do is add a new action after that email. [clears throat] For... Sorry, it might be Attributes. Update field. Yeah.

So Attributes, not Actions. And then we want to have that field be called plan_type. So you can just copy and paste that. And then for the value, you can copy and paste this.

So this is another example of Liquid and what these double squiggles mean is it's like inject this value, is essentially what the double squiggles mean. So we're having it inject event.details.plan_name, so Pro or Lite or whatever. Click Save. And the reason we do this is that, as I mentioned before, event details are ephemeral.

The moment someone leaves this flow, it's gone forever. And in the case of what plan someone purchased, we don't want it to be gone forever. We definitely need to know six weeks from now who's a customer of what plan. So it's really, really important that we capture what was purchased in a permanent way.

It doesn't have to be a custom field. It might be a tag. But somehow, somewhere, we need a way in Bento to know who's a customer and who's a free person and who isn't even a free person. They just signed up for some lead magnet or whatever.

And the next thing we'll do is the other way of having that permanent record, which is adding a tag. In this case, like For a SaaS, maybe somebody can only be in one plan. But for me as a course creator, for example, people can buy multiple courses from me. So I would never want to say course purchased and then set it to the value of one of my courses, because they could buy multiple.

What I typically will do will be tags and/or more complex fields where it's a bunch of comma-separated names of courses, and then I could later do a contains check. So let's say it's course A is one and course B is another, and this was called courses purchased. You could find your subscribers like, courses purchased contains course A. You could do that.

But again, as always, you want to be careful, because if you have course A V1, course A V2, both of those would match course A contains, and you need to make sure you're happy for that to happen. So you have to be intentional with your naming. And that's why we'll do tags for now to keep it simple. So we will right click, go to Attributes, go Add tag, and then the tag to add, we can copy and paste from here.

We will add signup-event.details.plan_name plan. So if the plan name that's passed through is called Professional, this will add a tag called signup professional plan. If the plan coming through is something like professional plan, the tag that gets added will be called signup professional plan plan. So that's something to be mindful of.

Injecting liquid like this into a tag is, in my opinion, kind of risky. So typically what I would do would be not this. What I would do instead would be to branch based on that event name and hard set it. Unless I'm wanting that level of flexibility, like in that e-commerce example with a million products, you would probably not want to branch and do things manually.

But for a SaaS where you might only have [clears throat] five potential options, instead of dynamically naming a tag, which is kind of error prone, what I might do instead would be adding a magic split or a field switch, I think is what I said I would show here. Yeah, field switch. So what I might do in reality would be field switch, where we will split, in this case, on plan type, because field switches cannot set on a split on event details as of now, only on custom fields. So if I were doing it for courses, I wouldn't do it with a field switch.

I would do it with probably some magic splits. But nonetheless, [clears throat] you could say professional here and light here, and that'll have these two branches coming out. And then instead of doing this dynamic injection, I would hard code each. So this one's professional, this one's light.

I would do sign up professional plan. That's what I would probably personally lean towards, and then they can still both merge into whatever thing's going to happen next, like this. This is what I would usually lean towards, or the magic switch equivalent. Sorry, magic split equivalent would be essentially a chain of these where you would say...

And this is what I was kind of messing with earlier. I don't want to make you watch the whole typing. So now you don't have to watch it because I just skipped it. So you could do something like this.

So if event.details.plan_name is professional, then it's true, otherwise it's false. And what you can do there is [clears throat] have a new attribute add tag that is, quote, "hard-coded" to the pro plan. So we could do like this. Like that.

And so what this will do is it'll essentially say, if the thing that they bought is the professional plan, evaluate to true, which will go down this left branch. Otherwise, evaluate to false, which goes down the right branch. And then this node here, you would do the same thing, except checking for light. So we could have this.

And again, we're going to talk more about Liquid later, so don't worry about the actual syntax right now. But it would go down this branch, and then if they were evaluated as light, then we would add them to the light plan. [typing] Like that. And then you could even do some nifty thing where if they hit the one that they should never hit, we send an internal email. So for this false branch, you could send it to yourself and it's like, "There was an error." And that's a good way to know that something's messed up.

Because I think that's one of the scariest, hardest things with email automation is you don't necessarily know for sure when something's broken until one of your subscribers responds in confusion. [chuckles] But I digress. This is a little side quest. I just wanted to show you that. I'm going to go back and set it up the way I'm telling you to set it up.

So I'm going to just delete all of this, and I will do Attributes, Add tag, and I'll just paste that in. Wire that up. Save my progress so far, and let's see where we're at. Yeah, I think I covered everything.

One note is that I often use the pattern of tags with the word flag. This is less important now with Bento. It's just an old habit from back in ConvertKit days. I would have certain tags that would be called event-blank But that's silly in Bento because you don't need to add event specific tags, you just fire events.

But having some sort of name spacing where it's customer-pro plan, customer-lite plan, can be useful because then you can, if you want, take advantage of that contains matching where it's like, if they have a tag containing the word customer, do this stuff for them. Assuming you don't have a tag called not a customer. [chuckles] Assuming all of your customer tags are the only things that have the word customer, then that could be nifty. But you do you. Whatever makes the most sense.

I just wanted to note that down. We will get more into all this Liquid stuff in the "How to Use Liquid in Bento for Epic Power" lesson, so don't worry about it for now. For now, all I want you to do is test what we just made. So we'll build a little test trigger chain.

Because all of this stuff relies on event.details.plan_name coming through. But when you manually fire an event on a user's profile, you can't pass event details. It's just the event name. So what I like to do is create little testing chains where we have some test event name that then fires this event and passes event details into it.

So that's what we'll be doing here. So whatever naming convention you like for your events, whether you're doing the little underscore or spaces. You probably should never do spaces. I don't know why I had this here.

So boom, gone. I will copy this over with the dollar sign. So we'll do a new trigger, new event, and I will paste that in. So test_signup_dataflow, save changes.

And then what we want to do is connect it to one trigger, [clears throat] like fire off event action. So not trigger. Action, create event. And then what we'll do is fire off the signed up event, AKA the one that fires off the left-hand chain.

We want it to trigger that. So $signed_up, and then this is the important part. We want the event details to contain plan_name as the key, and then Professional as the value. And note that Professional has a capital P here.

Save changes. And we'll connect them. Update again, and I think we're ready to test it now. So basically the way that this'll work is if we fire this event, it does not need any event details.

And this event only exists to create a spoof event of this that doesn't require us to actually go physically sign up with a user. So I use this pattern all the time, like for testing product purchase and stuff. Once the whole flow's done, I do like to test it for realsies, like actually go buy the product from my cart in test mode and stuff to make sure the user gets all the stuff. But when I'm building out the flow in the first place, I'm usually just firing off little test events like this so that I can surgically test different parts of it to feel pretty confident that it's going to work well.

So now we can do exactly that. We will test the flow this time, not from firing the event on the profile, and instead with the Bento test suite. So first we need to switch that into live mode, save it, and then we can click this Run button, manually add user, and I'll do this for the [notification sound] Gmail one. So we have that. [clears throat] And then we want to choose our test one, and then we can just click Start Session.

Make sure I'm not missing anything. Cool. Yeah, we're not. I will trigger this now.

So I was going to say before I trigger it, but no. While it's triggering, though, I will show you something important. So in this case, we're doing it for this one, and it looks like this person maybe has a first name of Z. Yeah.

This person's first name is Z, and their last name is S. So what we expect to happen here is we expect the subject line to say, "Welcome to the Professional, with a capital P, Plan, lowercase z." That's what I expect the subject line to be. So let's see what we got. Cool.

We got exactly what we expected. First name here, pro plan here. If some of that data was missing, it would've swapped out the defaults, and that's what I show in the screenshot. So the word friend and the word there would've shown up instead of the person's first name.

Then what we want to do is pull up their profile in Bento and make sure everything happened as expected. So refresh, and what we want to look for are two things. First off, they should have a tag now called signup-professionalplan, and they should have a custom field that says Plan Type, Professional. If you did something wrong with your Liquid injection, what would happen is they'd probably have a tag called signup- plan, and they probably wouldn't have anything at all for plan type.

Because, again, when we're doing this add tag thing, we're injecting the event details in the middle of a string. So this whole string will get set either way, and this is why earlier I said I wouldn't typically do it this way, because you may end up with a bunch of bugged subscribers who are just called like... I'll make it. Hold on.

There you go, like this. You might have a bunch of subscribers just in your email tool as signup-plan, which would be not helpful for you because you would have no idea what they bought, and you'd then have to manually reconcile all of these with your purchase history in Stripe or whatever. So if you followed along, at this point, you should be in good shape. If they received the email, they got the right tag, they got the right field, then you did everything correct, and go you.

Most Bento users do not get this far and do such complicated stuff, so I'm really impressed by all the progress you're making. Great job. And we'll get even more crazy and do even more complex stuff in the coming lessons. So I'll see you in the next one.