In this video, I want to give you a quick little tour of doing backfills, as they're called, for imports and other bulk operations. So the Bento import guide in the documentation will be your friend here if you're doing an import, and I want you to defer to that because there's so much in there. And I just wanted to quickly walk you through how I personally handle the process of backfilling, which is essentially for everybody who is brought in or already exists, doing a thing to all of the old people that the new people would have automatically happen. So a good example is, let's say you built some crazy cool automation thing where you could build this in Bento as a flow, where when someone signs up, it will call AI to ask that AI if it seems like this person's first name that they used is a legit first name or if they just typed some garbage placeholder.

And then based on the AI's answer, you do some stuff. If you built that in Bento right now as a flow that's triggered on signup, that's great for everybody from this moment forward, but what about all the other people that were here before? Or what about the people that you imported? That's where the concept of a backfill comes into play, and that's what I want to talk about here.

So here is what that example I just made up might look like. So you might have a flow where it's triggered based on someone subscribing, so it would happen for everybody. Then you have the AI path split, where you essentially would just say, "Does it seem legit?" And this would be an awful prompt, by the way. If you are going to do something like this, put more time into your prompt.

If I were doing this for realsies, I would put a lot more effort and edge cases and stuff into this prompt. But nonetheless, if the user had a first name, it would output here. You can see that by default, this one's previewing as this email, which doesn't have a first name associated. But if I were to change this to email, you would see it indeed outputs.

So you can use Liquid here. And then the AI will evaluate that, and if it says true, it is legit, go here and don't do anything with it. If it's false, it's not legit, clear it out. So if somebody signs up and they sign up with the first name of "Shut Up," [chuckles] now we don't send emails to them that say, "Hi, Shut Up." Which would remind them that they didn't want to be on our newsletter, and that's why they used the throwaway thingy.

So supposing we had that, this will work for everybody moving forward, but we now need to backfill it. And so this is what I wanted to walk you through. Typically for backfills, what I'll do is I will create a new special event trigger that's just for the backfill. So maybe this is called Backfill.

And you don't have to use the word backfill. Could be TMP or whatever. Typically, if I do plan to only run it once, I will create it, run it, delete it. But if you think you might need to manually run it in the future, that's fine, and you could leave it.

So that'll affect your naming. So Backfill Evaluate First Name, let's say. And this is a new trigger event. Now you can just have this get triggered whenever somebody has this event fired.

One note is that if you're doing an import first, you'll want to do that import, get everybody brought in, and don't have the tags fire events, and try to avoid any triggers of automations, because that'll potentially do things that you're not expecting, so that you can manually merge in the data that you need. And when running imports, I like to specifically tag them with whatever marks the import I'm doing. So if I'm importing in batches or if I'm importing from a platform or whatever, I want to be able to know, did this specific subscriber come from my first import or my second one, or what? That way, if I make any mistakes, I can be surgical about auditing the data.

The main risk factor is sending emails to people, because once you've emailed somebody for the first time, now if you email them the same thing a second time, you potentially have weird user experience things. So when I'm doing these kinds of big imports, or just big data change operations, where I'm the most mindful is about emails that get sent or about changing preexisting data in a way that might break it if I can't recover it. And so by trying to import them without events getting fired and without any of your automations getting triggered, it allows us to get the raw records first, spot check them, make sure they look good, and then run one backfill for one type of transformation. So in this case, the first name clearing out/approval.

Make sure that worked, run the next one manually, that kind of thing. I just like to be very careful with this stuff because it's scary to mess things up or send emails to people that you didn't want to send them, et cetera. So all that said, here's the process. Step one, build the transformation flow.

So we did that. So that's what this is. This is a data transformation flow. It doesn't send emails, doesn't do anything.

All it does is enriches the first name by counterintuitively unenriching it. [chuckles] We're clearing the first name for people who we don't know the first name of. So that's done. We built the flow. Step two, we would want to test it.

So as I mentioned, this is pretty lazy AI prompt. I would want to actually test this with a bunch of different test subscribers that have different first name values. So usually when I'm doing AI stuff personally, I'll test it in Claude or ChatGPT first. But then once it's dialed enough there, I like to also test it on platform because we don't know what Jesse's system instructions are.

We don't know how calling this here versus in ChatGPT or Claude, where these tools have all of the memories from past conversations. It's just not as clean as doing an API call like what we're doing here. So I would test a few subscribers here that have weird names, edge cases, a missing name, a long name, someone signing up with Barack Obama. Just all sorts of things to make sure it works well.

And once that's good, then we can actually run it for everybody. So doing this manually for subscribers, this is just what we've done before. You would grab this event name, pull up a specific subscriber you wanted it to run on. So let's say we wanted to do it on this guy, create event, fire the event.

That's all you'd do. You can also do it in the back end here under the Run menu, just like always. I'm not going to cover that here because we've covered it in other places. And then once you are certain it's working well and you've tested it manually, that's when we do the backfill, and we do it in bulk.

So for that, we go to the main Subscribers page, I think. Yeah, Bulk Edit is right here. This is where all the bulk operations happen. And remember earlier I said that we wanted to use specific import tags and stuff, this is a good example of why.

So you can edit the rules so that you're targeting subscribers just with that specific import tag. So Tags Contains Import #1, and now we're only targeting the users who were in Import #1. And what we can do is, number one, fire that event. So we can do Create Event, paste the backfill.

And if you wanted to, you could also do other things to mark the process. So it could be like Backfill Step #1 Done, or Main Kit Import Backfill Step #1. You can add this tag to them to track your progress. That way you can know if you ran this on somebody without having to guess based on a name.

Because in this case, we're not actually doing any logging on the user's profile to say that we already ran this. So if someone has a blank name, we don't know if they have a blank name because this automation cleared that name or because they simply didn't join with a name. You would have to guess. And so you can either, A, have this flow always for everybody, keep track of if it was done.

Like suppose you had a custom field, probably you would have it above this. So if you were to do it for everyone, I think this would be clutter. I probably wouldn't necessarily do this, but you could do AI Name Processing Status, and you could set it to Complete, something like that. And then that would probably happen before the split so that we don't have to worry about connecting it in both paths.

And then this would happen for everybody. So this'll happen for the backfill people, happen for everyone moving forward, et cetera. But again, for this specific piece of data, I wouldn't personally log that because it's not a very valuable thing to log. In this case, we really just need to know it for the backfill purposes, and that's where adding a tag can be useful.

And so from here, if you click Draft Bulk Operation, I'm not going to actually-- Well, I guess I could draft it, but I don't want to execute it. It'll show you a preview of who it's going to run on. You can Approve Change and it'll run it now. And Bento will send you, I think it's a CSV.

It's been a minute since I've done one of these, but Bento will send you a CSV export of everybody who's about to get touched before the operation. So at least there's some backup, and then it'll perform the operation. But if you made a mistake and you needed to revert it, I think you would have to reach out to Jesse and have him do it manually. Don't think of this as a safety net.

Think of this as a very permanent, irreversible thing so that you are so sure that it's going to work before you do it. That's what I would advise. One other thing I wanted to note that I don't think is quite as relevant here, because most backfills happen for imports and stuff. But nonetheless, if you ever are trying to backfill sequence, so let's say you created some welcome sequence for all of your free plan members, and you added three emails to it spaced out by two days.

So it's about a one-week sequence, and you had 1,000 people totally go through it. They entered, they got all three, they left, they didn't upgrade. And then now, six months later-- Well, not even six months later, that would be too long. Let's say two weeks later, you augment that sequence a bit more.

Maybe the three email sequence was just a minimum viable product to get it shipped, and now you've put more time into it. Now you've got six emails. And you've added those three new ones to the sequence, but there's a problem. Those 1,000 people who already completed the whole sequence, they've left it now.

So they will not receive these new three. So if you want them to receive the new three, that's where this Backfill Sequences guide is relevant, and it's a pretty similar process to what we just covered. So what you could have done if past you had thought about it, past you could have added an email to the very end of that sequence that had a bajillion year delay before it, or in this case, 27-year delay, so that the people all stayed in that sequence and never actually were able to complete it. But past you didn't do that already.

Past you already didn't do that, so past you, goodbye. Now, present day you needs to backfill them, and that's where this flow comes into play. You can just do exactly what we just did, except, where are we? Instead of adding an event or whatever, pretty sure you can add to sequence.

Yeah. So you could target the people however you would target them, and then you could just add them to that sequence again, and what'll happen is they will skip those first three emails they already received, and they will just start from email four. So that's your option there. You can read the Backfill guide for more detail there.

See you in the next video.