So in this first example video, I'm going to show you how I've built out some modular lead magnet flows for my double your freelancing business, this one, so that I can scaffold out new lead magnets pretty easily while managing a lot of the complexity that I have in Bento. So the main challenge or problem to solve is that I have this evergreen newsletter within Bento that emails everybody who's eligible every week or whatever. And when somebody signs up for a new lead magnet, we might want to pause those emails while they are going through the welcome sequence for that lead magnet. So we need a system for managing somebody's eligibility for these different things and making it easy to create and release new lead magnets that people get welcome sequences for.

So the basic setup in Bento that I have in place is that every individual lead magnet with a corresponding welcome sequence gets its own flow that handles the sending of the first thank you email that contains the link to the lead magnet, and then the welcome sequence itself. I'll go into this in a little bit more detail, but the thing that is the key here-- Oh, man, it blurred this. I'm trying to find a way to blur out my subscriber info without blurring out everything else. This obviously didn't work.

All right. Maybe this will work. Let's see. Yeah, look at that.

So the thing that's important about how this fundamentally works is that I have this one event in Bento called lead magnet fulfillment init. This is a generic event. But that event carries event details of the lead magnet slug and the trigger for this specific flow. The trigger looks for that lead magnet slug being set.

Jesse recently, at the time of recording, got rid of this advanced event trigger node, which I actually really like that one. I don't like the new trigger node as much. So if we wanted to create this from scratch with the only one that's there for now, you would have to use the advanced Liquid filter and essentially do all of this stuff with that, which I think will be a little more complicated. Maybe he'll bring it back.

I'll probably flag this for him. But in any case, this is how this one works. They have to have this event name, and this has to be in the event details, and since this is the welcome email, we pass through the skip welcome email as true if we want to skip the welcome email. So in this case, we only send the welcome email if skip welcome email does not equal true.

So this basically gives me flexibility that if I wanted to add somebody to the lead magnet itself or mark them as getting it or whatever, but not send the welcome email, I could do that. One thing you'll notice that I like to do for complicated flows like this is I use comments with a hit Enter a bunch of times within it to make them really tall so that I can draw out little sections and keep myself organized, with notes about how everything works and use boxes as these dividers and little SOPs when I need them. And earlier in the training, I gave some guidance about how I use these sticky notes to annotate stuff, and you'll notice that most of these have little sticky notes just to remind future Zach how all this stuff works. And I'll talk about how this actual welcome sequence gets triggered, but you'll notice the main difference is that over here, this one was lead magnet fulfillment init, and this one is lead magnet sequence init.

So both are generic, but both pass that lead magnet slug, and that's the backbone of this modular system. And then from here, nothing is really that fancy. We send the emails, we do the business day delay, stuff we talked about before. And I'm basically using my flow to orchestrate the emails rather than a sequence.

This is typically how I send automated emails is in a flow. This one here is a newsletter that is also in the welcome sequence. So I have a little bit of logic that mirrors how my evergreen newsletter works so that I actually basically here in this split, I make sure somebody's shadow newsletters received field does not contain this newsletter slug in order for me to send it to them. So I'm not double emailing them the same email.

And as you'll learn in that other example video, the way that this flow pretty much works for the newsletter is first I check if somebody has received the newsletter. If not, I send it to them, and I add it to their shadow newsletter field. And this here, basically, I first set a temporary field of the issue that we're merging, and then I call an event that merges it in that function, this shadow newsletter merge sent email. It's basically just a tiny little function in a flow in Bento that looks at the custom field for that temporary value, appends it to their newsletters received, and then clears out the temporary field.

So that's what this little chain is doing, and then it flows into the other email. Everything from there is pretty simple, and the main thing that we're doing within these welcome sequences that's interesting is finding a way to mark the welcome sequence as active separately from marking the lead magnet as opted in for. And so that's what we can see if we go here and I search lead magnet in my tags. We see this lead magnet has both an opted in tag, which somebody receives, and then they keep it forever.

And then a welcome sequence active tag, which gets removed when they either complete the welcome sequence naturally or unsubscribe from it. And that's why there's this disparity between the two. So that's the high-level overview of the chains. Where are we?

The chains within here, one of them is the welcome sequence chain, one of them is the fulfillment chain. And so now the next part is the overall orchestration So now for the generic modular orchestration part. So we were previously within one specific lead magnet, and then this flow here is called All Lead Magnets. So this is the one that essentially fires off the one we were just looking at.

So from within my N8N automation, I fire off this custom event, lead magnet opt-in by slug, and that's what kicks off this automation chain. And the first thing that I do in here is, first off, subscribe them just so that they are indeed subscribed. This is important if somebody unsubscribed before, we need to mark them as indeed being subscribed. And then you'll see prior to these splits and stuff, you'll see that we are sending that fulfillment email.

So the one that's like, "Hey, here's that thing you downloaded." We fire off that event, pass in the details that it's expecting, so pass in the lead magnet slug from the event details, and this is what makes it modular. Whenever from N8N or whatever, whenever I call this event, I always need to pass that lead magnet slug in order for everything to work properly. And so we call this event with the lead magnet slug, and then over here, as I showed you before, it's listening for this event with this specific slug. So if this lead magnet slug was passed, it'll trigger this chain.

If a different one was passed, it would trigger a different chain. And if one was passed that doesn't correspond to any chains, nothing would happen, and it would be like a silent error. And then before going into all of the heavier tagging and adding to the welcome sequence and stopping the newsletter and stuff, I first make sure all of the required fields are actually set. So for example, I made this little magic split where I essentially look and say, "Was there a lead magnet slug?" And then later I could add a bunch more checks.

And if any of the big problem ones happened, I could just set it to false so that they don't continue any further, and we don't try to do stuff for them if they don't actually have a slug set. And this is important because down here we're going to add a tag called lead magnet slug-welcome sequence active. So if we didn't check first to make sure that I actually passed a lead magnet slug, some subscribers could technically get empty space-welcome sequence active, which would be bad. If I wanted to make the error a little bit louder, what would be smart is instead of this just ending the session, I should probably go to Actions and then Send Internal Email, and then send an email to me myself saying, "Hey, Zach, you done messed up your automation, bro.

Go fix it." But I haven't done that yet. And you can see I have some to-dos marked here that I don't even know if I did them. I often forget to come delete my to-dos, but I feel like this thing's working. People are signing up for the thing.

And then this here is an important one, and this is why I created that welcome sequence active tag. So something I've noticed in DYF a lot is that sometimes people opt in for something and then like a minute later they opt in for it again if they don't get the welcome email or whatever. People very often opt in for things that they are already receiving, and we need a way to guard against that because Bento won't natively guard against it. If I fire off this trigger event for somebody five times and I don't have any guards, it'll send five concurrent versions of this flow to them.

And that's one of the considerations with flows versus sequences, is if you keep adding somebody to a sequence again and again, it doesn't really matter, at least as far as I'm aware. They'll still only receive each sequence email once, but flows are not that way, so you have to guard against double adds. And in the past, I've done things where I use the-- Oh, gosh, where is it? Under Splits and Logic.

No, I always miss this one. The one where you can kill versions of a flow. Why is this so hard for me to find? Hold on.

Okay. It was just off-screen. Splits and Logic, End Flow. So I would fire this, and I would kill the welcome sequence flow so that I can re-add them.

But then that's also not great because if they've received two emails from that welcome sequence and I just kill it, now they're going to start again if I re-add them, which wouldn't be a good user experience. So this process here of just not adding them again if they're currently in it, to me is the best solution. But it requires that we have some way of tracking if they're currently in it versus not. And so my solution there was that dynamic welcome sequence active tag, which gets cleaned up when they naturally end a welcome sequence.

That's what I was showing you here. And then it also gets cleaned up if they unsubscribe from it. And that unsubscription I handle in the global orchestrator. So if they end a specific lead magnet sequence, like they say, "I don't want this anymore, just put me back on the newsletter," that's a special trigger link that I have, which I'll show you in a second.

And then additionally, if they globally unsubscribe, so they're like, "Zach, I don't want any of your emails anymore," we also will kill the straggler session and remove them. The way that I chose to build this from a modularity perspective is that there's no way to, from the main orchestrator, kill all the lead magnet flows, but the flows can kill themselves. And so what I have here is that within one of the lead magnets, it's just this pre-configured boilerplate where I call it suiciding itself, basically. And so if the lead magnet kill straggler sessions event is fired with the slug for the lead magnet we're in, we remove that [lips smack] welcome sequence active tag from them, and we end flow.

So not end session, but end flow of the one that this one is So this basically kills itself. And then additionally, if they globally unsubscribe, so we send the all lead magnets one, it would also do it. So this essentially allows each time I clone this template that this one starts from, which I have essentially in my flows. I have lead magnet to-do slug.

So this here is the template that whenever I make a new lead magnet, I just clone out this flow, and I have little to-dos marked for myself of all the stuff I need to configure. This is the process for making a new lead magnet flow in here that works in this ecosystem and stuff. So they'll just clean themselves up that way. And I was just checking, and actually I misspoke a little.

Right now, I'm not doing any trigger links to unsubscribe just from one lead magnet's welcome sequence, at least not as far as I'm aware. And right now, I kept it simple and just did a global unsubscribe. But typically for that kind of stuff, when I've done it in the past, the way that I'll do it is with a flow that handles just segmentation trigger links. And basically, when somebody clicks-- So I have this.

Let's see if I've got it in my history. No. Hold on. I'll find it.

So this. I've got this page that I made, so it's just my website /preferences-noted. And then basically, whenever I want some kind of trigger link, I will append a specific action, a unique action, to the end of that URL. So I can use this same page for everything, but what matters is that within Bento, I append this kind of query string.

So it'd be like question mark like this. Preferences noted, question mark, action equals this. And so when this happens, the Bento link click trigger will come through with this data. And so in this case, email link clicked contains this.

And then I can do whatever they're asking for. So if I were to have people unsubscribe from one sequence, so I've got this. They can opt out of podcast ones. They can opt out of this wait list thing, whatever.

That's how I would do that for these sequences. I just haven't done it yet. So that's the build. Is it overkill for most use cases?

Absolutely. Where you would only ever need something like this is with a build-out like mine, where you want to be able to stop certain things from happening while this other type of thing is happening. That's kind of the backbone of this, is if I wanted to keep it simpler, when somebody signs up for a lead magnet, I could just add them to a sequence. But then what about if I want them to get those sequence emails again?

I don't know if you can even do that in Bento. I'd have to double check. Or what if I don't want them to receive the normal newsletter while they get those sequence emails? Or what if I want to control what happens if they're in two sequences at once?

All of these things that my obsessive brain, I guess, when thinking about the email user experience latches onto, and you kind of have to do something like this to control and get visibility into how people are flowing through. So hopefully, this was useful and sparked some ideas and wasn't just overwhelming.