What's going on everybody, Nick here, and in this video I'm going to run you through an advanced Make technique called breaking up your scenarios. I've had a lot of people ask me when and why I break up my scenarios, and in this video I'm going to show you everything you need to know to master this admittedly quite advanced. make.com skill.
Without further ado, let's dive right into it. All right, so I'm going to show you exactly what I mean by breaking up a scenario in a few minutes. I'm going to jump into the editor and I'm actually going to do a live for you with an example. Before I do, I just want to cover sort of like the conceptual basis for why I'm talking about this.
And first of all, a lot of you guys are probably wondering, like, what does Nick mean by breaking up a scenario? And what I mean by breaking up a scenario is basically where you use webhooks and the HTTP module to feed the output of one scenario and make that the input of another scenario. This allows you to chain together tons of different scenarios, especially ones that have variable runtimes and especially ones that use AI, because sometimes AI modules take five seconds to finish.
Sometimes they take 30. Usually this involves some. sort of naming convention, some type of numbering, some type of folders or whatnot. And if you don't have a good structure for this, this can get pretty complicated in and of itself. And generally it's useful when your average number of modules in a scenario starts running above 15 to 20. So what do I actually mean by this? Well, when I said that we are feeding in the output of one scenario and turning that into the input of another scenario, I have sort of an example scenario over here.
And I'm just going to call this like example output. And what I have is I have a basic trigger set up for for scenario number one. And this basic trigger, this is just like a, you can just click this plus, go to tools and just do basic trigger. This is sort of just like a set variables module if you guys aren't familiar with it. What I'm gonna do is I'm just gonna set the output of this to five.
So we have an item or an object, or I mean collection if you wanna call that, with a parameter where the name has a value that is equal to five. If we run this, you'll see that the output of this is five. That's as expected. All breaking up a scenario really means is, hypothetically, that's a way of a very. complicated scenario.
This isn't just one basic trigger. This is some big 20 module step flow. And then the end of the output of it is five. All this really means is you take this and then you feed it into an HTTP request module. And then what you do is you call a web hook in another scenario to continue the flow.
And you do this outside of the first scenario. You do this in literally like a fundamentally different scenario because it allows you to shuffle data back and forth, allows you to stay a lot more organized and allows you to do quite a number of like advanced to make.com flows. So I'm actually just going to build.
build out the simplest example for you right now. If this scenario number one is called example output, we're going to call this number two example input. What I'm going to do is I'm going to create my own webhook. I'm just going to call this example breaking up scenario webhook, just so I know to delete this later. Then I'm going to copy this address to my clipboard, and then I'm going to paste this in as the URL to my HTTP request module.
A lot of people don't realize that you can do this. You can send data to another make.com scenario in your flow just by using HTTP. HTTP requests. So the very first thing I'm going to do is I'm just going to run this, just so you guys can see how this works. Just like we call a server, you can also call a make.com scenario.
So as you see here, I called the scenario, and I'm just jumping back to the example input here, and then I received a request. Now granted, the request had no data whatsoever. It was a completely empty request.
But that doesn't mean that it has to be an empty request. We can do a lot of things with this. We could feed query strings in.
We could say output equals five. If we run the same thing, oops, sorry. We're going to have to use the existing data of that run. You'll see we now have an item that has a variable name called output and then a value called five. We don't even have to do a get request if you want.
You can also do a post request. You could feed the data in as raw JSON, and you could have output, and you could do five. I'm going to remove this query string, go here. I'm going to run this example, and I'm going to send the data back. we get the same thing.
The reason why I'm showing you all this is because there are basically like a million and one ways that you can use HTTP requests with webhooks in Make to create like very complicated and complex infrastructure. You could have tons of different scenarios all running interactively between one another and the really cool and really valuable part about this is this basically allows you to eliminate the issue of where you have like tons of bundles coming in as an input and then than you hitting the make.com timeout limit, which I'm going to talk about next. But anyway, I hope it's clear.
That's basically what breaking up a scenario means in this instance. I'm just referring to using a webhook and an HTTP module to communicate and shuttle data back and forth to one scenario and the next. So it's pretty cool.
The obvious main question is, okay, why would I break up a scenario? Like, Nick, aren't you all about just making money extremely quickly and not having to worry about all this academic bullshit? And the answer to that is yes, I certainly am. But there are many situations in which you actually do want to break up scenarios. All right.
Even if you're trying to be a scrappy. hacky as possible like I usually am. The four main ones here are it's less messy, messy, less messy.
I'm the messy of make.com baby. It's less messy and more visually pleasing. The second is it lets you avoid make.com's like 40, I think it's 40 or 45 minute timeout. And that just means like a scenario can only run for 40 to 45 minutes before make.com will actually say, hey, stop the scenario and it force stops it.
So you can imagine how like if one of your tasks is to iterate over 5,000 rows and every row run takes like two seconds or something. That's 9,000 seconds, which I believe is, what, 150 minutes or something? My math ain't so good. But the point that I'm trying to make is you wouldn't actually be able to go through every single one of those rows. So what you can do with this is you can actually run a, you can call a webhook, basically, HTTP request, send the data somewhere else, and then you don't have to wait for the data to process.
You just deal with all the processing time in the other scenario. And that scenario just runs once every single time you call it. It's also more modular and more maintainable later on. does necessitate that you have good naming conventions, good folder structure, all that fun stuff that I mentioned earlier.
If you don't, it can actually be a little bit more complex, but I'll show you guys a very simple naming scheme that I personally use. And then it also lets you implement more robust error handling. And this is something that a lot of people probably don't know about.
I haven't covered it in my make.com course up until now, but you can send responses to webhook requests, like make up your own status codes. Basically you could say like 200 means good, you know, 400 means no, you know, 401 means unauthorized or whatnot. I think it means one author. Unauthorized.
Yeah. Okay. Good.
It means unauthorized. You can basically do this. And then in the main scenario, you can do a bunch of things with the response to that information, which is pretty cool. And then you can have some pretty robust error handling and you basically just made it all yourself.
And then one other reason here that I think it's good to at least start understanding how to break up scenarios and why you might want to break up scenarios is because this also just like turns you from more of just like a make.com no code script junkie into like an application developer, essentially. Like you learn that, you know, you're basically making several endpoints. You're shuttling data to and from these endpoints.
You're starting to basically build an app, essentially, like almost like an API, like your own API. So that's why I would break up scenarios. There's certainly a couple of other reasons here.
And, you know, I'm sure there are other people out there that have broken up scenarios in different ways, maybe not with the HTTP module, but maybe using some different apps or whatnot. But this is how I do it. And this is one of the most scalable ways I think you can quickly transition from just like a make.com script junkie into. to like an actual developer, which is pretty neat. And that takes me to the most important part of this video which is when the hell should I actually go out and break up a scenario.
And I will show you four, or I will talk about four instances and then I'm actually gonna dive into a scenario that I've set up here called my content syndication scenario. I created this one in a previous video and then I'd show you what this might actually look like in like practical terms. And how we'd eliminate the make.com like timeouts and how we do a bunch of other things.
So first reason to break up a scenario a scenario or when to break up a scenario is when the modules have variable run times. So basically any time you're using AI and then you're iterating through a large number of bundles, you're going to want to do something like this. The second is obviously when you're iterating over a large number of bundles, say 100. The third is when you have many routes with many modules and it's getting disorganized. And the fourth is when you're running a module with a callback URL. This is sort of a fancy programming term, but there are tons of modules out there where you basically you'll run it in one module, like you'll run the process in one module.
and then it's like sent over to the cloud or to the service and then you set a callback URL and you basically have to wait for the results of that module in another. So I'll show you guys what that looks like as well. But yeah these are the four reasons that you might want to break up a scenario, four ways to know when it's a good time to break up the scenario. And now what I'm gonna do is I'm gonna show you like a practical example of me breaking up a scenario and actually like what I would do and what this would look like realistically.
Thank you Ryze, much appreciated. Alright so without further ado this is a scenario that I set up. up a little while ago that essentially we have an air table over here and this air table just has a couple of columns this is an example scenario i'm not actually using this for my business but you know you guys wanted me to do something like this a few weeks ago or maybe a month ago and then i whipped this up we basically just have a content calendar with a date column here a copy column an image url column and then we have a list of platforms we're not actually using this list of platforms so we could actually just delete this um so we have a date column post copy column image url column and then why is this not there we go and then image url column and basically this is just meant to be like a social media calendar where we have post copy like hey think recycling is just about saving cans it's more than that recycling does blah blah blah blah blah then we have an image url over here which is just like an image of i don't know i guess some some dirt and some plants and stuff and then what this make.com scenario does is it takes this data okay downloads the file that's what this hutp module does and then what it does is it actually goes out and then um It creates.
and publishes social media posts to different platforms by using AI to customize the copy and you know ideally like the image resolution and stuff although I don't do it here um to those different platforms for instance if it's a twitter post what we'll do is we will take in the copy and then inside of this right twitter post it will say um Not that. Convert the following post copy into formats for Twitter. Don't include any backlinks.
Use N in place and U lines since it's Twitter. Make it short and punchy. The input we feed in is some long post copy and then the output is like some very short Twitter copy with emojis and stuff like that.
The idea is we basically like the motivator here is you just want to I don't know your team to be able to write one post once maybe a short little piece of copy here have an image and then have that automatically kind of fit to like five different social media platforms all you need to do is just click a button then we actually go go through and we will upload the media, we'll create the post, we'll do all that fun stuff. Now, one thing to keep in mind is let's say, I mean, in this example, we're only using three rows, right? We have like one, two, three.
But let's say hypothetically, we, for whatever reason, wanted to post, you know, 50 posts today, okay? 50 posts today times five GPT-4 modules is 250 GPT-4 runs, right? If every GPT-4 run hypothetically, let's just... just say took 15 seconds.
Now we're at 3,750 total seconds for this whole scenario, which is 62.5 minutes, which is more time than our scenario would basically be able to run. Make would have to time it out. Now this is a very contrived example, obviously. You're probably not going to try and post 50 times in a day or something like that. Maybe you will, I don't know.
But the motivator here is, you know, we have a lot of modules with variable run times, and it'd be much, much more efficient if instead of worrying about all of this stuff, we could just send it off to a different scenario with an HTTP request, which would take like 0.1 seconds, and then iterate to the next one, essentially. And so the reason why I picked this is because there are four different routes. So we basically have to create four scenarios to sort this out.
And you see here, we have one run here, which is this like creates a an article in Medium. This one here creates a post in LinkedIn, this one here creates a post on Twitter, and this one here creates a post on Facebook. So how would I actually go about like breaking up the scenario? First and foremost, I would have some content syndication onto Twitter, Facebook, Instagram, LinkedIn, and Medium. I have some very descriptive title, which I've already set up.
And then I'd use a numbering scheme. And then what I'd do is I'd add this to a folder. So I'm actually going to go to my scenario tab here, and then I'm going to say content syndicator flow.
I'm going to look up my scenario here. I'm going to drag this to my content syndicator flow. Keep in mind, I've renamed this in this tab, but I haven't actually. Oh, if this ever happens to you, by the way, it's just because you've selected some text elsewhere on the page.
So this is just like if I do this and then I save, I'm going to get this every single time. But if I just exit out of this and then save, then I don't get that anymore. Just in case one of you guys got this.
I'm going to name it. So I don't know. Let's say trigger Twitter, Facebook, Instagram. I don't have an Instagram one here.
So Twitter, Facebook, LinkedIn, and Medium post flows. Let's do that. And I refresh this so I have it.
And then what I'll do is I'm just going to create a scenario. for Twitter, Facebook, LinkedIn, and Medium, and then I'm going to use webhooks to tie them all together. So I'm going to create some scenarios here.
I'm just going to do this one at a time because then I'm going to do one fully, and then that way I can just copy it to the next one. But what we want is we want a custom webhook. We're going to say example breaking up scenario.
Let's do Facebook first. Save this. I'm going to copy this address to my clipboard, and then I'm going to go back over here, and basically what I want to do is I'm just going to unlink this, and then instead of these modules, what I'm going to do is I'm going to send a request.
to make a request here. Go back here. And I'm gonna call this, call Facebook post flow scenario.
Maybe let's just remove flow. Let's just make it scenario. easier for you guys to understand i would say the url i'm going to feed in is this and then what i'm going to do is i'm going to have um let me think i need to feed in the data obviously so i could use a get i think in my case i'm going to use a post and you don't need to like use different ones every time just pick one format and then use it all the time and then what i need is i just need the post copy and then i need the image url so i'm going to put a variable here called post copy and then i'm I'm going to feed in my post copy and we may have to deal with a new lines here and then I'll go image URL and then I'm gonna feed in the image URL okay great this looks good to me and what I'm gonna do is I'm gonna link the rest of these just so we could test this one fully and once we know that this works we can go back and then copy and paste and do a lot of fun stuff let me just delete the rest of these example scenarios and then I can use this fully and what I'm gonna do is I'm gonna call this Facebook post scenario. Receive trigger and run Facebook post scenario.
Let's do that. And then good. I'm going to run this.
And then what I'm going to do is I'm just going to, let's just do this on one post for now. So I'm just going to like change these dates again, back to six, seven, eight. That way my air table flow is only going to select the one with whatever the date is. Actually, you know what?
Sorry, I'm using a formula here. Let me just grab the first result. Let's just run this and make sure we got it.
Okay, great. Yeah, we have the first result here. So what I'm gonna do now is I'm gonna run this. I'm going to go through the flow and then I'm gonna call my Facebook post scenario, which is why I have this testing. It's currently awaiting input.
I click run once. And then it looks like there was a 400. Yeah, so there was a 400. And the reason why there was a 400 was because we ended up adding a bunch of new lines in between the JSON here. This is actually not like, and you know what, I just had a question come up. up in my community you can't actually pass like new lines like this to json so what you have to do is when you pass the copy you have to replace all instances of a new line character here you have to replace that with a backslash n and then you can just regenerate the new line later but anyway so i'm going to run this again And then let's see why there was a 200 here.
For whatever reason, this did not actually take it at the time. I'm not sure why that didn't happen, but obviously we did end up getting the data, which is nice. Let me run this again and run this again. Okay, there we go.
Must have just been a little bug. And now you can see we've actually regenerated the new line here. So despite the fact that we removed the new line character and then we just had like a back session, we now have the new line character in again for our post copy, which is cool.
Okay, great. Now all we need to do is we're just gonna copy these two. Right, these were parts of our Facebook post flow. And then we're just gonna map the modules and the data.
So I'm just going to feed in my post copy. Wonderful. Then all this Facebook stuff, I need to feed in download photo from URL. So I'm just going to feed in the image URL here. I'm not going to add a caption, although you could very easily generate a caption.
Right. So I don't actually want to post this on my Facebook profile for one second copy. Let me see.
Why don't I actually just do this once just for brevity? And then after I'm not going to post on any other Facebook. or Instagram or Twitter profiles. I'll just do this to show you guys if this works. Okay, so now let's actually run through this whole scenario, and then let's actually post this data.
So I'm going to run this, and now we're awaiting our input. I'm going to run this here. Now we're sending our input. We received our input. We're now writing the Facebook post.
Now we're creating the Facebook post and posting it on my profile. And I'm going to jump over here, give it a refresh. Looks like we have pasted it in.
We posted the JSON, looks like. Oh yeah, we posted the JSON, my bad. We're gonna have to jump back here and change this.
because the output is a message in JSON. It's because I told it to write in JSON. So we don't actually want it to write in JSON. I just want it to write the copy. Okay, there we go.
All right, let's do that one more time. Let's just eviscerate my Facebook profile. And now I am going to refresh. Refresh.
And we have our lovely post over here. Well, with the backslash ends as well. That's funny. So we can't actually just post this.
We need to replace the backslash ends with new lines characters. There we go. Okay, third time's the charm. We're going to delete this and then rerun. And then, okay, great.
It looks like we posted it again. Now I'm going to refresh the page. If it doesn't work, I am eating a shoe. Okay, great.
Yeah, so it worked. We have the new lines and everything looks nice and sexy. So that's what that looks like.
You know, in my case, because I run the pages, it's published by Make. And that's how you know that, you know, make.com was responsible for that flow. I'm going to delete that. And I think it's pretty clear at this point how all of this is going to work.
Essentially, now that we've done this for one, all we really need to do is we just need to repeat this for a few more scenarios. So I'm going to go into my scenario editor. I'm going to refresh this and then open up the folder that I created a moment ago called Content Syndicator Flow. And I'm just going to create a new scenario here. And then what I'm going to do is I'm just going to paste this in.
And then why don't I use the same naming convention? We'll say 3 and we'll say run Twitter post scenario now. Oh, and then because I copied in the webhook, I already have a webhook URL here. So I need to create a new one and then assign a new URL, which is right over here.
I'm going to go back over here and then I'm going to move all this stuff, copy and paste this in. We are going to get the webhook address from the first, paste it in and then instead of Facebook post scenario I'm going to rename this to stay organized we'll go Twitter post scenario then I'm going to copy all of my work here and keep in mind this is specific to Facebook so I'm going to post in my Twitter one I now know that there are a couple changes I need to make to this to make it work I can't say output in JSON okay so it doesn't look like I said output in JSON for this one which is nice I need to feed in the post copy variable. If you don't know what the variable is called, you can map it still. You just have to know the variable name. And then if it's not currently available in the selector, you're just going to get this little outline, this little red outline, whatever the module color is.
So that's what I'm doing here. I know this is the post copy. And then I also need to download this specific one.
So I'm just going to exit this out and then get the file from HTTP. I'm going to feed in image URL. I believe that's called image URL. And then I'm going to get the output of this image URL module.
Feed that in. All right, great. So now we have our Twitter scenario up and running, which is pretty cool.
Why don't I do everything except for upload the thing to Twitter just to show you guys how that might work? So I'm gonna go back to my initial scenario here And then I'm gonna remove this Facebook route just to show you guys what it looks like if I call the Twitter post route just To verify that works So we see sent the request, we received 200. If we go back to our Twitter scenario, we see we got the data with the post copy image URL. We wrote the Twitter post. The result of that was this. And then we got the file and now we have a bunch of binary data.
So we can kind of connect this to the rest of this flow. And that's what that looks like. This is what this looks like. Oh, sorry.
I selected the text again. And now we can do the same thing for LinkedIn. We can do the same thing for Medium.
So I'm just going to follow the exact same process that I had. I had before for both of these. This is going to be called LinkedIn post scenario and this one's going to be called medium post scenario. Beautiful. And then I need to go and create another scenario.
Let's do two more scenarios really. One for medium and then one for... LinkedIn.
So we're gonna do a webhook here, a little custom webhook. I'm gonna go webhook here, custom webhook. This is the first webhook for the LinkedIn, so example breaking up scenario LinkedIn flow.
Let's go. okay and i'm going to add this paste this in we'll go medium flow okay and then this naming convention here is really good i really like this so i'll go for receive trigger and run medium post scenario and then we're going to go five sorry linkedin post scenario and then five run medium post scenario and then i'm going to copy these addresses and then i'm just going to feed them into these http modules so linkedin post scenario is going to go here and the medium post scenario sorry is going to go over here Paste that in. Okay, great.
Now we have four flows, basically. I mean, just look at this. This is much shorter and much sexier, I would say, than what we had previously.
And we can also just hide all the complexity away and put them in the specific scenarios that are relevant. So this is the LinkedIn one. So I'm going to paste in what I did for LinkedIn here.
We are going to write LinkedIn, and then we're going to say... Since it's LinkedIn, make it corporate longer and dress it up a bit. Okay, great. I think I didn't actually copy the data over correctly when I attempted to make this scenario earlier, so it's probably not going to write this.
This is as well as I probably could have if I had trained it better, but that's okay. And then just like we did with the Twitter scenario, we have to download the file here for LinkedIn. So I'm just going to paste this in. Let me copy this and then go back here.
Oops, I guess I was lagging a little bit. We'll paste this in. And then I'm going to grab one image URL which should work and then I can just map the output of this. Okay, great.
So now we have the LinkedIn scenario up and running. Last thing we need is we need the medium scenario and then I'm just going to delete all the rest of these because they're no longer relevant to us. The medium scenario here is going to get pasted in and then we are going to write the markdown article and the way we're going to do that So we're going to go 1.PostCopy.
Wonderful. And we also need to do the same thing for the title. 1.PostCopy. Then we can pump the output into medium, which is already nicely formatted, and voila.
Yeah, that's great. All right. Now, what do we have when all is said and done? Well, we've basically converted our flow, and we don't actually need this module anymore. We've converted our flow, which previously was, I don't know how many modules in total, probably like 20 modules in total, maybe 18 modules in total, something like that.
We've turned it into a scenario that now only has five modules. So it's substantially simpler at the front end. We were very organized and informative with how we...
titled the various modules in our first trigger scenario. And as a result, we now have like a very organized folder based system, basically, where one master parent scenario will trigger all of these flows. And then the other four scenarios will sort of, you know, go and do their bidding, basically do what they were supposed to do here. As it stands, this is pretty basic as far as breaking up scenarios into multiple, you know, sub flows is what What we could do, for instance, is we could go into one of these scenarios and then use the webhook response module.
We could say, let's pretend that the output of this Facebook page module was a 400 or something like that. Or what we could say is... You know, if hypothetically this scenario didn't work, we could say post incomplete.
I don't know what we'd use to basically tell us if the post is incomplete, but then we can actually send back a response to the webhook originator and we could have like a status code incomplete. Let's say, sorry, status 400, and then we can have like an error and we could say incomplete. And then when this scenario runs, and if this one's complete, we could return a 200. And then we could have no error at all.
And now when this scenario runs, aka when it's called from the call Facebook post scenario, when we run this, we could actually... get a response that would say you know 200, 400 or something like that inside of this module which would then allow us to do some more complicated error handling like maybe if we call Facebook post maybe I don't know there's like two or three different ways you can make a Facebook post so maybe if we call Facebook post scenario one and it doesn't work, well now we call Facebook post scenario two. And that's where you can start getting in like the very complex flows where, you know, this is Facebook post scenario one, and if this doesn't work then we call Facebook post scenario two instead, and then if that doesn't work maybe we, I don't know, we like log the error to our database or our CMS or something like that. And in this way you've basically built in a ton of redundancy into your application and your application is now like it's not it's never gonna Be an enterprise application if you're making it in make make just is a little too slow and it consumes a little too many resources In order for this to be feasible Make optimizes for usability of like the developer, aka you, and not necessarily like infrastructural completeness and that sort of thing. But you can get pretty close.
And then you can apply all the concepts that you've learned here to actually go out there and then make like a full stack enterprise app if you wanted to. right? You can use Make as like an MVP and then just take the exact same logic that we've done here where we have different endpoints to run Facebook posts, Twitter posts, LinkedIn posts, Medium posts, and then actually like build out an app that serves hundreds, thousands, or maybe millions of users. All right, hope you guys enjoyed that video.
Hope it wasn't a little too academically dry for all y'all, but I think if you've made it to this point in the Make for people that want to make real money course, it's important for you guys to learn like some of the finer points behind, you know, breaking up scenarios and how Make works at a higher level and that sort of thing. If you guys have any questions about this advanced material, please leave a comment down below and we're happy to answer you guys. I'm going to do a few more videos on advanced concepts, so I just want to get a pulse or read the room and see where everybody's at with this level of knowledge.
And then otherwise, please do all that fun YouTube stuff, like, subscribe, get me to the front page. And yeah, really appreciate your time, looking forward to the next video. Have a great rest of the day.
Bye-bye.