Overcoming Make.com Platform Limitations

Hi, my name is Nick. I made over $72,000 per month with a make.com agency, so I am no stranger to the platform. In this video, I want to cover some of the unexpected limitations of make.com and then how to fix those limitations to allow you to surpass what I think the developers of the platform intended. So I see these problems all the time in my own make.com communities. I see them on YouTube and I see them on the wider web when I'm picking up a new project or helping coach somebody through a problem. In this video, I'm going to run you through everything you need to know in order to identify these problems and then solve them. So I got a little cheat sheet set up here just to add some more value. We're going to be using this cheat sheet as the source just to keep us organized. But I want you to know that if any point in time you find yourself not remembering what I talked about here, you're not entirely sure how to overcome these limitations, just click the link below, pin it, bookmark it, just have it somewhere with you. I include not only the problem, but I also include multiple ways to solve the problem. And what we're going to be doing now is we're just going to be going through each and every one of them. So the first major limitation in make.com is that there are no built-in delays greater than five minutes. What do I mean by this? Well, I have a little scenario open here, okay? And pretend just for the purposes of this example that this trigger is something in your business. It's like a HubSpot field being updated. It's a new form entry coming in. It's a new email that you've watched. And we just want to do something with this, but we don't want to do it right away. What we want to do is we want to wait. We want to wait exactly one hour. How would you solve this in make.com? Like actually stop for a second. And if you have any experience with make, just ask yourself, how would I solve this problem in make.com? It'll make the rest of this material stick more. Well, what many people are probably going to think of is, well, there has to be some built-in way to do this, right? And they'd be sort of correct. There's a sleep module that delays an execution for a specified amount of time. So they might drag and drop a sleep module. They click on it and they try and ramp up the delay. It says the number of seconds for just scenario execution will be suspended. Okay. How many seconds is it? One hour, 3,600. Click that. Oh no. The value is too big. The maximum value is only 300. Well, if we convert 300 seconds to minutes, that means that the maximum delay that you can actually achieve with this is only five minutes. Okay. So your next logical step is probably, well, if I can only do this for five minutes and I want to wait an hour, why don't I just create a bunch of these? And then I'll just chain them all together. I'll do 12 in total. And then I'll wait five minutes, five minutes, five minutes, all the way forward. Well, that's another unfortunate reality that you can't do. and make.com because scenario timeouts are 40 minutes. And because of that, if you try and execute a scenario that's longer than 40 minutes, I think they have a five minute grace period or something. So it might actually be 45. But if you try and execute a scenario that's longer than 40 or 45 minutes, it'll just time out and it'll break. So you're going to do nothing with your flow. So how would you actually solve this problem? Well, what I'm going to be doing is I'm just going to try and solve the more general case, which is how do you do any delays longer than five minutes? And I'll cover three scenarios. The first is how to get up to about 40 minutes or so. The second is how to get up to one day. And then the third is how to get up to like an infinite variable amount of time. Let's say you want to send an email in the year 2029 for some reason. Well, I'm going to show you how to do that using a pretty straightforward approach. Okay, so solution one is just use multiple sleep modules up to 40 minutes. So that's that's pretty straightforward, right? It's basically what I just did. If I just paste here, and by the way, I'm pasting by holding command and pressing V, maybe I'll call this something more district descriptive, please. We'll go sleep five minutes. And then I'm just going to copy this, I don't know, let's say four times or something. And I'm just going to wiggle these a little bit. So they connected the scenario and then I'll click auto align here. What we've basically done is we now have a flow that when I execute it is going to wait five minutes, wait another five minutes, wait another five minutes, and then wait another five minutes. This is 20 minutes. You can realistically do this up to about 40 minutes or so. Keep in mind that if you try and do this at exactly the 40 minute mark, you may run into some issues because every time a module executes, It also takes a little bit of time, right? It takes like a fraction of a second. So make.com's timeout is 40 minutes. You might have 40 minutes or yeah, 40 minutes worth of sleeps, but then you might have five seconds worth of scenario execution. You're actually going to go over that. You might break the scenario. So that's the simplest way to do it. That's probably what the vast majority of people here are thinking. The second way to do it, and one that I personally use all the time, is I use a platform called HookDeck. Okay. Now, what is HookDeck? HookDeck is basically... in my case, it's, it's free or it's a very low cost way to send a request from make.com to hook deck, have a hook deck, do something with it. And there are multiple things that you can do with it. You could like wait a certain amount of time. You could delay a request. You could filter a request based on parameters. You could run a function on the request, right? There's a lot of stuff you could do. And then after the specified amount of time, hook deck can just send it over to your make.com scenario. Again, in this case, it'd be a different scenario and then do the thing that you wanted to do. So the really cool part about this, and I'm not sponsored by HookDeck at all or anything, just to be entirely clear, I just love using HookDeck and use it for a lot of my flows. The really cool part about this is this allows you to queue requests up to one day. And this is what I want to say, probably 80% of all delay use cases will fall under. So basically, in order to be, you know, 80% good for all of your delay needs in the future, you basically only need to know solution one and solution two. But let me actually run you through what this looks like. Now, obviously, first, you have to make an account in HookDeck. You have to set everything up and, I don't know, you know, verify your username and password and shit. After you're done, just go over to connections and click on this little connection button. And this is where you're going to set up the logic for your hook deck flow. Now remember, hook deck is just like an intermediary. So you need to send something from make.com over to hook deck and hook deck is going to catch that just like a web hook. And then it's going to do whatever you want with it, like wait a day, do some filtering function, whatnot. And then it's going to send it back to make.com. That means that we need something that sends a request to hook deck. And then we also need something that watches for a, um, like a web hook from hook deck as well. Uh, so what I'm gonna do is I'm gonna create a new source. We're just going to call this example source for YouTube. Let's go delay source. And I think the popo is coming because this video is fire. I'm going to get shadow ban for my shitty jokes. And then we need to define an event destination as well. Um, so what I'm going to do here is I'm just going to say example, delay destination for YouTube. And you'll see down here, it says endpoint URL. Well, this is where we actually need to set up a scenario that does the thing that we want to do. So in this scenario, for instance, we have a trigger, right? And then we have the action, which is the sending of an email. What we need to do in order to make this work is we'd actually have to take the trigger and we'd have to make the trigger one side of the scenario. Then we'd have to make the email part another side of the scenario. So I'm actually going to have to create a new one. So why don't I go like 1A, no delays. And then over here, I'll just make a new one and I'll call it 1B, no delays. And what we need to do at the beginning is we need to send this via HTTP request over to HookDeck. Okay. And we'll fill in the URL that we're sending to in a second. And then on the back end, what we need to do is we need to catch that request with a webhook. So I can write the word webhook correctly. And then we actually need to create and then copy the address to the clipboard. And we need to paste this down here. This is going to be the end point. Okay. So we're going to have source. Source is going to be called example delay for YouTube. That's going to be our first scenario, right? 1A. Then we're going to send it over to HookDuck, catch it. HookDuck's going to do some shit with it, and then it's going to send it over to this endpoint. That's sort of like the logic, the way that we've set it up so far. Okay, and now is the important part, which is where we define our connection rules. There are four main connection rules with HookDuck. There's transform, filter, delay, and retry. All these are pretty cool, not going to lie. I'll walk you through each of them. Transform allows you to do something to the data that comes in. Basically, you can actually write your own function. and then you can take the data, modify it with something, and then you can spit it out. So that's pretty sweet. Obviously you need a little bit of coding knowledge in order to really be able to take advantage of this. I like using this function a lot because it's just a quick and easy way to do things that make.com struggles with inherently like string processing and stuff. And then it allows you to save a lot of operations because you're technically doing this inside of another platform. And then you just get the finished result in make. Um, you can use Amazon web services for this as well. Uh, the next is filter. So same sort of idea. You basically have some, um, I mean I'm not entirely sure of the syntax, I personally don't use this, but you can filter the event so that it has to have like a key and then a value equal to something. This is a little bit more nuanced of a requirement. The third is delay which is obviously what we want. So we just click delay, we can delay this request for one second, or you can even delay this request for a day if you wanted to. You'll notice if you go two days can't be over 24 hours so you do have to max it out at one day. I think HookDuck may be including some functionality that allows you to delay longer. than a day at some point. I don't know if maybe you need a premium account for this or how that works. And then the last is retry, which is where you can retry every certain amount of time. Anytime you get an error code from the endpoint that you're sending to. So again, a little bit more complicated, but if we try and just solve the simplest one, which is to delay, and then instead of one day here, right, I don't actually just want to wait a whole day because I want to show you guys what the request looks like. So I'm just going to click a second for now, but keep in mind, if you were to actually try and do this, you'd want to do this for a whole day. I'm just going to name. the connection here and then we'll click create and now what we're going to do is we're going to use this url to receive your requests from example delay for youtube valid request this url will be sent to your destination example delay destination for youtube and hook deck will reply immediately with an http 200 so i'm actually going to copy this now then i'm going to go back to our first scenario which is 1a i'm going to paste it in then the only thing you need to keep in mind with hook deck is you need to do a post request to this url um and you can send whatever the hell you want. Like if you think about it, what we want to do is we actually want to send the data from the previous step because we want to do something with it right so in my case i have an email message equal to hey how's it going that's actually what i want to send so i'm just going to create my own json here i'm going to call it like email message and then i'm actually going to paste this in okay and now what i'm going to do is i'm just going to run this once it's going to get the data from the trigger with the email message hey how's it going and then it's going to send it via http request as you see here the url i'm sending to is this hook deck Basically, I'm sending it to a webhook listener. And then the request content is email message. Hey, how's it going? And you can see that it's saying status success message request handled by hook deck, blah, blah, blah, blah. So clearly something is happening here. Something is good. Now you notice that you see connection was created. We actually sent the request and then we have a 400 error code. The reason why is because I didn't actually set up the other end of my scenario here. I actually didn't finish what I wanted to do. Let me just copy this, paste this email in, and then I'll delete this. Again, what we want to do is we want to catch it on the other side, right? I just forgot about that. And then what I'm going to do is I'll just go to dot email message because I want to grab the email message from that second webhook and I want to send it out via email. And let's just try this puppy one more time. So I'm going to send this, just got sent over to hook deck. One second later, it fell into the second batch here and then it sent it over through email to the email address that I had specified. The email address that I had specified was just naked left click.ai saying, Hey, how's it going? So So again, I did this in one second because I just wanted to show you guys a quick example of how this works. Ideally, you would do this any time period up to a day. This is one of the quickest and easiest ways to set up a delay time yourself. Using HookDeck, you're basically just swapping this as like a sleep module you can think of it as. So that is solution number two. Solution number three is a little bit more complicated, but this is like the general solution. This is the thing that allows you to deal with any instance of the scheduling or delay problem. however long in the future it may be. And with this, what you do is you create a request spreadsheet and then you just pull it repeatedly. And I'll talk a little bit in the future about why pulling isn't very good. And I'll show you some ways that you could eliminate pulling. That's another unexpected limitation to make.com. Um, but this is still a pretty solid way to deal with the delay problem. Let me run you guys through what I mean by this. Okay. So let's say, you know, our previous example, what did we want to do? We wanted to send an email, um, and we wanted the email to include an email message. Hey, how's it going? Let's say instead of this super simplistic example, what we actually have is we have like the email that we want to send. And we also have like a date that we want to schedule it at. And let's just hypothetically say, right, it's December the 3rd, 1137 a.m. right now. Let's say I want to do this on like December the 4th or something like that. Let's just go December 4th, 2024. This would be a simpler example. I'll just show you the date. So actually, I want to wait a whole day to send this tomorrow. Let me show you guys how you'd set this up. The first thing you need to do is you need to go into some database. I'm going to use Google Sheets in this instance, simplest thing that you can do. And I'm just going to call this, why don't we do like email scheduling database. Now what you do is you make a column for the thing that you want to send. In my case, this would be email message. Then you also make a column for the date that you want to send it. So this would be date scheduled. Awesome. So we have our two columns here. This is going to be the database that we're going to be using to schedule requests. and then execute on those requests. And then you still need two scenarios here. So we need a 1A, we need a 1B. What 1A is going to do is 1A is going to take the data from our trigger, which could be a form, it could be a HubSpot thing, it could be anything you want. And then the first step is it's going to send this over to the Google Sheet, it's going to add it. So let me see email scheduling database, sheet name, we only have sheet one. The table does contain headers. It has that email message and date scheduled. We're just going to put email message here and then date scheduled. Okay. So I'm just going to run this once. It's going to send this over to our Google sheets database, right? And now we sort of have, um, we have the scheduled message. Now on the one B scenario side of things, what we have to do is we have to set up a Google sheet and we have to search the rows using the search rows module. So let me just hook all this stuff up to the right Google Sheet. This one was called Email Scheduling Database. Just to remember, we're going to be looking for spreadsheet equal to Email Scheduling Database. Perfect. Sheet names is going to be Sheet 1. It is going to contain the headers, right? And then let's just return one response to start. The reason I get this red bubble every so often is just because when you go a little too fast, it tends not to work. Okay, so great. So we just ran this. And as you can see, we have an email message equal to, hey, how's it going? And then we also have a date scheduled for December the 4th, 2024. That's good. That's what we wanted. Now what we need to do is we need to set up logic basically to check the sheet. once a day, and then to only return the records that have a date equal to today. If you think about this logically, right, what's going to happen? Well, if we run this once a day, every single day, we're going to be running through all the records. And then we're just going to be checking is today's date equal to the date that it was scheduled for? If so, we're going to proceed. If not, we're not going to proceed. So very simple and easy way of running through this. Let me show you guys what this looks like in practice. The Google Sheets Search Rows module has a filter setup, so we can actually check to see if date scheduled is equal to the current date. Now the way that you do this using make.com, you know, you can't just type in like the now date. What you have to do is you have to go over to our calendar, we have to go to now, and then what we have to do is we have to format this date so it's in the same format as whatever the date is in like our Google Sheet. So this is going to depend on however you or the trigger puts in the data into. um, Google sheets. So in our case, it says DEC, so that's sort of a three letter month code. Then it's a space, um, for space 2024. So, uh, there are some IntegraMAT date time tokens here that you can check out that allow you to do this formatting and parsing really easily. In my case, because we're doing December DC, we need an MMM that we need to add a space. Then we need a D that we need another space. Then we need a year, year, year, year. So I'm going to go over here. I'm going to format this date as MMM. space D space year, year, year, year. What this is going to do is it's going to grab the current date, which is December the 3rd, and then it's 2024. And then it's just going to format it so that it's MMMDYYYY. And then, you know, this is, this has a schedule for some of the fourth actions. This isn't actually going to work if I run it. Let's go back to December the 3rd. And let's actually right click, run this module and just see if we get the data. Good. We got it. And now what we need is we just need to add our email module, which I unfortunately deleted. So let's just create a new one here. It's actually put in the logic and we're going to send this to myself. And then the subject is going to be, this is a scheduled email message with the value of this being email message. And now I'm going to set the schedule to run every day at let's just say 8 AM. But keep in mind, you can make this as granular or precise as possible. For instance, if you wanted to schedule down to the hour, you could write down the hour as well, and then use like daytime parsing using those tokens I showed you to pull out the hour. And then you could run this every hour to check and see if this is the same hour. But now, right, if I set up a filter, I just want the total number of bundles to be equal to one. If it's not equal to one, then I don't want it to proceed, right? Found. Otherwise, we're just gonna be sending a bunch of empty emails. And then, you know, this is going to run daily at 8am. Let's just pretend right now it's daily at 8am. Great. As you can see, we ran through this, we found one record, and now we're sending an email. And now if I go back to my email, see this is a scheduled email message. This is what I was looking for, which is pretty sweet. So these are the three ways to solve the no delay problem in make.com. Again, to recap, the first way was just adding a ton of sleep modules. You could get this up to about 40 minutes or so, but you can't go any further than that. The second way was using hook deck, which enabled us to get up to about 24 hours or so using their built-in sort of catch delay and then send feature. And the third way was building out our own database of requests, adding to them using one scenario and then searching through that scenario or searching through that database, I should say every day with the second scenario until you find something and then connect it to that, uh, that second, uh, action, whatever it is, whether it's send an email or update a record or. I don't know, you can get pretty fancy with it these days. You could even have it like connect with some handwritten letter API and send something out. Whatever the hell you want to do, you can. So that's unexpected limitation number one. Unexpected limitation number two is of a similar vein, and it's where testing forms takes forever. This is a problem that I've found with a number of no-code platforms, and make.com in particular struggles from this because there's no way to get the data from the form and then just keep it in the no-code builder and then just run it. What this means is if you have like a really intense, a very long form, every time you want to test your flow, you have to fill the whole freaking form out. And I don't think you guys realize exactly what this means to your productivity, but I figured it out pretty quick. Like if it takes me a minute to run a form every time I want to do a test and I test a flow like 50 times, I'm developing it. I just added at minimum 50 minutes to my flow, like two to my testing or building of that flow. Um, I'll show you guys a couple of quick and easy ways to solve this. For instance, let's say I have a scenario here. that just watches the responses on a type form. And the type form that I'm filling out is some trial for, you know, working with my company. So it's called the automator trial. First, you have to track your time and clockify. Then you have to do this thing. Here's a brief. You have to paste a video link. You have to write how much time it took you. Then you have to send an invoice to us. Let's actually run through and let's, let's just fill this out just as a quick little example. I'm going to run my scenario. So I'm going to run this now. So it's going to be watching for responses from this. Um, then I have to click this button to click that button. I have to click that button. I have to put some example video. I'm going to just use a Google drive. I'm going to have to go one Oh four. I'm going to click submit, right? I mean, that took us like 15 seconds that we didn't really need to be spending. And now I have an answer. And, and, you know, every time I want to do something with this, I'm just going to use a set variables module. Every time I have to do something with this and I want to see what the data is, I basically have to run through this thing again, right? Like I click run once, I just have to wait. And then I have to go into the type form, refresh it, fill the whole form out. It's just, it's mindless. Not only is it mindless, it also just takes a lot of the time away from the time you could be spending driving actionable results. And then you also kind of forget about what you're doing when you fill out that form so many goddamn times. I'm going to show you guys a better way. Um, the easiest and simplest way that I've found is just add a sleep module after your type form, and then just add a delay. Um, I'm using 30 seconds now, cause I've found that type forms API starting to take a little while longer to update. And then 99% of the time, whatever form platform you're using, there's usually two modules of interest. There's the watch responses or watch submissions. And then there's the list submissions, list responses, search responses, search submissions, get submissions, get responses. Sometimes they have different names depending on the platform, but that's generally the two classes. You have something that like watches for new ones, and then you have something else that like just gets all of them. And so in Typeform, for instance, what you have is you have one called list responses here. So what we're going to do is we're going to watch the responses. We're going to wait a certain amount of time. Then we're going to list the responses. And I'll show you guys why I'm doing this in this way. It'll make perfect sense to most of you in a second. The form ID we're going to be pulling the data from is going to be the automator trial. And then the limit is just going to be one. Okay. So look what happens, right? If I run this once, and now we still have to wait to fill out a form request, and that's going to take forever. It's going to take us 15 seconds every time we want to test. Well, what if now I just unhook this and I just drag this over to list responses. I run it. It instantly gets the data that I was looking for. So what does this mean? Well, it means that. Later on in the flow all you need to do in order to test your scenario is just connect all of the Variables to this module instead of this module So I'm just gonna say example variable and then anytime you want to test and see how the rest the flow goes you just click Run once it gets the data for you And then you can actually test and see the actual run and then when you're actually done and you're ready to make this flow production All you do is you drag this over to the walk watch responses module, you connect it, and then now you don't need to do anything else. Your whole scenario is basically production ready. Um, this does take you two extra operations per scenario run, I should say, right? Cause we have this watch response in this sleep that aren't technically necessary. Um, but because you're getting the data from this scenario or from this module, I should say, uh, you don't actually have to do any of the really annoying swapping. Like imagine if this scenario was like 500 times as long. Just unbelievably long, just so many millions of modules. If you did this the previous approach, or you tried hard coding the data or something, you would have had to go through every subsequent module and you would have to swap out the variables so that instead of calling this one, it called this one. Now you don't have to do any of that anymore, which is pretty sweet. So that's solution one. Just submit the form once, then use a list responses or search responses or whatever the hell it's called. If you're using something different like jot forms or paper forms, hello forms, and so on and so forth. The second solution, and this one is a little bit more general of a solution. It still takes you a fair amount of time because you do have to do that swapping that I mentioned, but you can, you know, because of this, you can, you could save a fair amount of the bullshit as well. You submit the form once, and then you take the output JSON and stick it in a parse JSON module. And then you just use that to test. Let me show you guys what I mean. So this is my scenario here, right? So I'm going to pretend that we're back at the very beginning here with this watch responses form. What I'm gonna do is I'm going to go grab a parse JSON module. And I'll show you guys why I'm adding this right now. But anyway, first we're going to run this. I'm going to go back to my Automator trial. I'm just going to fill out this form. So blah, blah, blah, some more boring stuff and 119 and then submit. Great. And then notice how over here, top left hand corner, we have a download input bundles, download output bundles. Sorry. What you want is you want the download output bundles. If you've never used this before, it's extraordinarily powerful because what you can do is you could actually just copy the json that you want and then you could add it to a um parse json module and then you could just instantly get the data for a test input and then just use that to test every output what do i mean i'm just going to copy what i care about which is these mapable answers over here and you do need to wrap this in just a pair of curly braces and then i'm just going to now run this module only and what you can see is we've actually like hard coded a test uh case where we have the key and then the value and it's just the same key and value every time because when we run this we had input json and output json in the watch responses module we just copied all the output json we stuck it in this thing and now we can just continuously run this however long we want essentially and then all downstream modules here i don't know let's say we're connecting to some some hubspot service or something you can just draw the data from the exact same thing that you had before right? The watch responses module. It's just this time it's like hard coded in the JSON. Bonus points are when you actually do go to update this later and you go to, you know, back to the form and change this, you notice that because the key names are exactly the same, you could still save a fair amount of time by just swapping out the module number. What do I mean by this? Well, um, the way that these variables are represented, they're actually represented in code. If you copy one and then paste into your URL bar, you see how it says this 16 dot mappable underscore answers, period space, and then the key, the key name. Well, if you just change the 16 for the two, copy this and then paste this back in here, this will actually reference this. And so instead of you having to like go through that drag and drop rigmarole, which I think a lot of no code platforms struggle with, but make.com in particular can be pretty annoying about, you could save yourself a ton of time just by like pasting into the URL bar, changing the number, pasting again, pasting the URL bar, changing the number, pasting again. So quick and easy hack that I've found to solve this for myself. And one thing that I use basically every day to overcome this unexpected limitation. All right, let's talk about limitation number three, which is errors and executions. What do I mean by this? Well, I'm going to show you guys a quick example. I have a scenario over here, and it's just sort of a fake scenario. But in the scenario, I have an HTTP request module that calls a URL called leftclick.ai zzzz. Now, there is no website called leftclick.ai zzzz. So when I run this, it's not actually going to complete. It's not actually going to be able to make it to, you know, the rest of the scenario. And that's actually a problem for us and make.com because a lot of the time, what you want to do is you don't actually just want to end the whole flow. Like anytime I run this thing, it's not going to make it to the second and the third sections. Like, like the second that there's an error, especially in like an HTTP request module, nothing makes it past this. So like hypothetically, if I want to do one thing, if it's successful, but I want to do another thing, if it's not, what the hell do I actually do? How do I actually make it? Right. What I'm going to show you is a quick and easy way that you can apply to basically any scenario that has an error in it that you want to route based off of whether or not the error works or not. I mean, that's called using the resume module. It's one of the fewer and littler known error handlers in Make, but the resume module is extraordinarily powerful. And ever since I learned about the resume module, quite frankly, I've started using it for more or less every flow of mine that has any sort of import. I think when you guys see the value in the resume module, you'll start doing so as well. Okay. So as we see, we keep on getting the service is not reachable connection error. Well, what we want to do hypothetically is we want to go down this route if it succeeds, and then we want to go down this route if it doesn't succeed. So what I'm going to do is I'm just going to call this success. And then I'm going to call this one here, failure. And you can imagine how we go down success to do something like we're calling, we're calling my website, right? In this case, maybe you're calling some. website and you would want to extract the data from it and do something cool with it. Maybe you want to use AI to get you the email addresses. Maybe you want to have AI summarize something about it. Maybe you want to run a regex or a regex, sorry, on the data itself and then run through it top to bottom to do something, parse, whatever. And we just want to be able to go down different routes depending on whether or not there's an error. The solution is just go over here to flow control, type in resume, and then connect resume to this HTTP request module. What resume does is resume will allow you to change. So first of all, it'll continue going down. Basically it'll say, don't stop this module here. And that'll allow you to change the output. If there's an error. Okay. So if there is an error, I want the status code to be 400, which I believe it will actually already be 400. And then what I want to do is I want to have routes that check to see the status code. And if status code is equal to 400, it's going to go down this route. Whereas if the status code here is equal to 200, which is just what it returns, if it's successful, it'll go down this route. Now for the second thing, I don't know, I just want to like example data. And instead of adding in the actual HTTP, sorry, HTML, I just want to do like my own HTML. Just as a quick little example, I don't think there'd actually ever be any use case or scenario in which you'd actually want to do this. But still, let me show you guys what it would look like. Okay, so what we saw there was it instantly failed. The second that it failed and we got the service is not reachable. We went over here and we replaced the status code with 400. Now we have a status code of 400, which allows us to route down to this second route and then do whatever we wanted with thing B. If hypothetically we didn't call that broken module or broken URL, we called the correct URL. It'll go up this top route. Oh, and it looks like there's just no, there's no data here, which is why that didn't work. So let's run that one more time. And then instead of going down the failure route, now it's going to go down the top route. And so in this way, we basically allowed us a much more dynamic application. Our backend is now not super fragile. It's not like the second that something fails, that's it. We need to crash the whole thing. We can actually control the flow of an error and we can do things with it that enable us to account for these sorts of problems. This is something that I, as I mentioned, did not learn until very, very recently, embarrassingly recently. So I'm not saying that you need to know how to do all of this super fancy error handling in order to make a million plus dollars with bank.com. But you do need to at least conceptually understand that errors end executions and you need to know sort of how to handle them and so on and so forth. So yeah, that's issue number three, which is a very unexpected limitation. Issue number four is that the default scheduler costs a lot. What do I mean by default scheduler costing a lot? Well, in Make.com, you basically have two ways of getting data and doing shit with it. So on the trigger module, you can either trigger every so often. So remember how back in our Google Sheets example, we triggered every hour or so, or sorry, every day to check and see whether or not there was a row in our spreadsheet with a date equal to the current date. Well, you can either use some sort of schedule-based trigger, or you can do an instant trigger. And if you think back to our hook deck example, where I was waiting for a request from hook deck, and then the second that I got it, the scenario proceeded, that's sort of like a hook-based example. So The issue in make.com is there are a lot of modules out there that don't actually have the ability to run instantly based off new data. And so they have to do the scheduler. And the scheduler is actually a lot more expensive than most people think about. I'll give you an example. The default scheduler with make.com, this little scenario here that's just checking my email inbox. If we click this button, it's going to be 15 minutes. I just want you guys to do the math with me for a second. If you run a scenario every 15 minutes, 15 minutes is four times per hour. Okay. That's four times 24 times per day. That is 96 times a day. That's 96 times 30 times per month, which comes out to, I don't know, 2,880. Is that correct? Yeah. 2,880 times per month. Imagine spending 2,880 ops per month on a single scenario. And that's assuming that that scenario, it doesn't have any follow-up operations at all. We're literally assuming the only thing that triggers there is this first module. That's crazy. If you look at like make.com's pricing, just have them spend a little bit of their ad budget there. Sorry, make. You'll see that on a monthly plan, it's 1882 per 10,000 ops. That means you're literally spending about a third of this, which is about six freaking dollars just on one scenario to do the scheduling. So it's crazy. You really should not be using the default schedule anytime you can. I mean, you know, $6 might not mean a lot to you. It certainly doesn't mean a lot to me at this point, but still, I don't want to get in the habit of just like having every scenario I run cost $6 because I have a hundred scenarios, right? If I were to do that, we'd start getting into some pretty shitty territory. So I have a couple of solutions to this. We're not going to be able to run through every single one, but I will run you guys through the default schedule or costing a lot. And I'm also just going to talk about just everything costing a lot of operations as well. Because it's actually not just the default scheduler that I wanted to cover. It's just like operations in general. They can cost a lot in make.com. Other platforms aren't necessarily as expensive as make or some of them are more expensive in different ways. Make.com is definitely like the operational cost scaling. So the first and the simplest way to solve like operational issues, particularly with regards to scheduling, is to replace all of your scheduling triggers with a single schedule. instant triggers instead. Those ones that I was talking about earlier that just wait for an event and then do something with it. So if we go back to our example here, this is probably the number one most commonly used module in email. It's just a watch emails module. And basically what people will do is they'll say, well, I want to do thing X every time I get an email coming into my, my inbox. Every time somebody, I don't know, um, raises a customer support ticket or something. What I want to do is I want to get that. And then I want to forward it over to somebody in my team. Sounds pretty cool, right? The issue with the watch emails module, which is the default one in the emails, I guess, class of modules is that it runs based off scheduling. And so two problems here. The first is that you're going to have to wait at most 14 minutes and 59 seconds, basically. Like what if an email comes in immediately after the thing pulls, you basically have to wait another 15 minutes to get it right. 14 minutes, 59 seconds or whatever. And then two, you're just going to be running this four times an hour, which is 20 or now 96 times a day, which is 2,000 times a month. There's a much easier and more elegant way to do this that actually runs instantly. and doesn't suffer any of those problems. And that's using what's called a mail hook. So instead of constantly pulling my mailbox, instead what a mail hook is, is it is a custom trigger that runs anytime it receives an email address to this string. And as you can see, it's very customized. Like this is the only email that exists ever. Sorry, every time this instantiates, like it's totally unique email. It's not like you're ever going to have any conflicts or issues with us. But what you do is instead of watching your email address, you just send all of your customer tickets over to this email address instead. And then I'm just going to run this now. And then the second that. an email makes it over to this mail hook and Google takes, I think, five seconds or so, which is why this isn't like instant instant. It's technically being queued up in Google's server right now, um, before it gets sent out. But when we receive it, we have all of the same information that we would have had previously. The only difference is we didn't have to wait 50 minutes and then we didn't have to do polling, uh, 2,880 times a month just to get this email. So that's solution number one. There are a variety of these little hacks here. Um, I just showed you how to do one for email. Another common issue is Google Sheets. A lot of people will do the watch new rows module. And basically this is similarly only going to run every time we watch or sorry, every 15 minutes or so. It's just going to batch all of the new rows added to a spreadsheet every 15 minutes, which is super inefficient and just not very smart. If we just go to, I don't know, all or something, it's going to run this. This is the same spreadsheet that I was using earlier as part of the email scheduling example. And you see that, you know, it just pulled in the data that we were looking for, right? But now let's say we want to add another one. Notice how it's not, it's not actually running. We're not actually getting anything. It's not like it just waits for it. What this is doing is it's basically running a poll every single time I execute this, which again would be 2,880 times a month. Now, if I added another row in here. I would basically have to wait God knows how long in order to receive that data, right? We basically have to wait until the next execution, which would be 15 minutes or so. I just did it instantly to show you guys. And then I also find anecdotally, this kind of fucks up with my testing quite a bit. If you were to try and like delete a row or whatever, then it'll just forget that you've, sorry, it'll remember that you've been to row three. And then when you add another one, it's not going to notice it. So you can get around that pretty easily in Google Sheets. You just need to add what's called the watch changes module. I'm not going to run through how to do all of these little optimizations, but the watch changes module is very similar to the watch new rows module. It's just, you have to go into Google sheets and then you have to install an app. So kind of annoying, but a little Chrome extension that you have to do. So this watch changes module is going to be under extensions, add-ons, get add-ons. So we'd go extensions, add-ons, get add-ons, and then I'd have to go make.com. Or sorry, I believe this had a specific name. Make for Google Sheets. Yeah, they don't do the, they don't actually say make.com in this. Where are we? And then you have to like add this in here and then connect this and, you know, do a bunch of rigmarole. The point that I'm getting at though is this just solves you having to do that weight. Okay. So that's, that's problem number one, which is a very big problem. And I think that, you know, probably already saved several thousand dollars in aggregate. The second solution to operationally intensive things. And so, you know, I realize now that I, I said that this was about a default schedule problem. Really? It's just like the operations problem in general. Default scheduling is like the main reason why though. The second solution to everything costing a lot of ops is to look into bulk or batch API calls. So for instance, let's say you're doing something with Google sheets. Okay. And I have a little scenario set up here that does something with this. This is something that I actually just used for a podcast campaign of mine a couple of weeks ago. Basically I have a big list of people over here. and email addresses. And this is a massive list of all of these people across all of these different industries. Typically the connection between them is that they do podcasts. And what I want to do is I want to send a request over to this spreadsheet. I want to get a record. And then what I want to do is add it to an open AI call that generates an icebreaker for that. Then I want to do another HTTP request that updates that row. And then I want to wait a little bit. So let's just look at what happens when I execute this. First, I get all of the people in this sheet, which is a lot of people, several thousand, right? Then I generate an icebreaker, then I update around Google Sheets, and then I sleep. What's really happening here? I'm consuming one operation to get the list. Then I'm consuming n operations, depending on the size of the list, another n operations, depending on the size of the list, and another n operations, depending on the size of the list. So basically, if I just like math this out, it's 3n plus 1. n just being the number of rows in my spreadsheet, right? Well, I can actually take this from a 3n plus 1, and I could realistically convert this into a n plus 1 instead, which, if you think about it, makes my whole scenario three times more efficient. The way that I do this, and I've recorded a video on this that I'm going to link in this YouTube video, so just check the top right hand corner of the screen at some point, and you'll have a link to one of my bulk HTTP request modules. where I show you guys how to do a bulk request to Google Sheets. But basically the vast majority of worthwhile APIs, they have like a way that you can add things in bulk as opposed to add things one by one. Google Sheets is one of them. If you go over here to Google Sheets, you'll see there's bulk add rows and then bulk update rows. There's also a make an API call module, which you can use as well. I personally use this one to do the bulk row updates because I find that it's a little more reliable. But essentially, instead of having to update the rows like we're doing over here, what you could do is, you know, you could just... aggregate all of the outputs of the GPT-4 module. Then you could just use this bulk. Oh, I guess we have to select my spreadsheet. So just give me one sec. Let's grab the actual spreadsheet ID here and then connect this. It doesn't look like we're finding this. I may be connected to the wrong thing. No, I'm not. What is this going to be called? NSM podcast campaign, right? This would be Apollo Leads Rapidly. Yes, this one right here. And the sheet name here would be just sheet one. The range would be, would it be like A1 to, I guess, AR2001. And then what you basically need to do is instead of adding just one. record at a time, you actually create your own array where every column in this spreadsheet here is one element of the array. So if I wanted to update this, I'd update this as like Allie. I have to go back and get their last name, Zewail. I have to do Allie Zewail and so on and so on and so forth. all the way until I make it to the end of the sheet. And then what I'm basically doing is I'm doing an array of arrays. And because of this now, instead of me doing, you know, I mean, how long was that sheet about 2000 rows, instead of me doing 2000 operations, which would basically consume a fifth of a whole month's worth of operations in a single run, I could just batch this and do them all at once. Now, in order to make this happen, you would need to do some fancy text aggregation stuff, which is what I show in the video. And I'm not going to run into the specifics of it. Basically, you have to make your own, you essentially have to like create your own formula here with the text, and then you have to map over all of the output columns and so on and so forth, and then connect them and turn them into JSON. But if you are using something like I was showing you here, at any level of frequency, you can usually save several 1000 operations a month, or even several 1000 operations a run, to be honest, just by implementing bulk HTTP requests, such as Google Sheets as a bulk. HTTP request module. You could do bulk add modules and air table. Um, you could do, uh, bulk batch AI updates like open AI is GPT for actually has a batch output. endpoint, which allows you to basically do the same thing. Instead of feeding it in one at a time, what you do is you get all those one at a times, you batch it into just some giant array, you just send it all there at once, and then wait until it's done. In this specific case, I believe it takes 24 hours or so that you have to wait, which may be a little bit longer, but there are many use cases which people are okay waiting 24 hours. Same thing with Claude, Anthropic has a batch endpoint. And there's just a lot of ways that you can minimize your operations usage and My point here making this video, specifically talking about unexpected limitation number four, is just point you guys in the right direction here. Know that you don't need to consume, like you don't have to spend $20 every time you run one of these things if you use bulk or batch API calls. Okay, the third thing I want to talk about is basically once I build a flow, I will run through that flow and I'll remove all of the modules that I consider unnecessary. So let me show you guys a quick little example here just using this scenario. what a lot of people will do, and they'll do this because they want to, you know, like keep track of their data and store where it is, or they just want to make things more easily accessible for them is they'll use the set variables modules very often. And typically what they'll do is they will remap a variable that comes in. So maybe instead of full name, they call the variable full name with a space instead of this underscore, and then they just map the variable in here. Then maybe we have another one kind of later on that just sets. another variable, maybe it's called like personalization, and then they'll remap something that technically is already present and accessible in make.com. But they'll do it using the set variables module, just so that like it's a little prettier, it's a little more accessible. This is fine to do when you're actually developing stuff. And don't get me wrong, I do this all the time. I recommend that people do this during the development stage. The issue is when you push to production, and that just means like when you make a scenario live, you are now paying for two additional operations. Consider that this is in total a six operation flow. So you've essentially just multiplied the number of operations you are going to be spending on this by something like 30%. So an instant way to reduce the number of operations you're spending in a scenario is typically just to go through and remove all of the purple modules. So typically like the set multiple variables modules, for instance. There are a lot of other ones here that aren't explicitly necessary, switch modules and whatnot, and then just delete all of them. And then instead of using the variables from the purple modules, just jump in and then remap them. So you're pulling directly from the modules that output those variables. So instead of me using that, like, I don't know, let's go over here actually. Instead of me using that other icebreaker, I would just use the one that comes directly out of my generate icebreaker module in GPT. This is just a little minor optimization. You're probably not going to be able to save, like I'd consider solution two here. Solution one and solution two, they're capable of saving you like a hundred times as many operations. This is probably capable of saving you like 30% as many operations, which is still fine. Okay. And the last thing I want to talk about is just the difference between iterating over multiple bundles versus using arrays wherever possible. So, um, as opposed to, you know, and we tie that, I'm going to tie this in a solution too, as opposed to us having to iterate through a list of a thousand records, and then one by one, send those records off to someplace. What you can typically do is you can just aggregate them all into an array using the text aggregator or some sort of array aggregator. And now you're only really working on a single element because in make.com, like a single bundle can contain an array that contains hundreds of thousands of elements. So in order to do this, you need to understand array aggregators, which is sort of like a special class of function. Not a lot of people fully understand them yet. They're probably one of the most widely misunderstood things in make.com. I've recorded multiple videos on iterators and aggregators and how they work. And I'm not necessarily going to recap them all now. I just want to show you that basically an aggregator is an inverse iterator, and an iterator is an inverse aggregator. An iterator will take in an array, and it will just split it into multiple bundles. And then an array aggregator will take in multiple bundles, and it will just convert it into one array. So anytime that you use an iterator, you could use an aggregator to turn that back into an array. And anytime you use an aggregator, you could use an iterator to turn that back into multiple bundles. There are a bunch of modules in make.com that have built-in iterators. anything that returns more than one bundle has a built-in iterator. As you see, this Google Sheets search rows module has a built-in iterator. It iterates through, you know, 2000 requests. So what I could do is I could actually just aggregate all of these by sticking in the array aggregator next to it, using this as the source module. And then I get to pick the fields that I want to aggregate, basically. Let's just say I want to aggregate a big list of first names here and, you know, a couple other things. And then if I just unlink the rest of this and run this, Despite the fact that we've outputted, you know, 2000 bundles here, we're not running this array aggregator 2000 times. We fed into it 2000 bundles. But the output of this is a single array. And that single array is obviously a lot more workable, I would say, on bulk. Even though it has 2000 elements, that single array is a lot more workable in bulk. You could do things like, you know, filter through to find the, to extract only the elements where the first name is Lawrence or something. And you could do it using maps functions. You could do this using sort functions and so on and so forth. You just don't necessarily have to muck up your monthly operations usage in order to do so. Awesome. So that is problem number four. Next up, I want to talk about problem number five, and this is alluded to earlier by my sleep module or delay problem. And that's that scenarios will inevitably timeout after 40 minutes. So big problem here flows that iterate over a large amount of data, like from a database, like Google sheets or air table, or ones that use AI or ones that use delays can exceed the 40 minute timeout limit and make.com, which is a problem. So I pulled up this scenario actually to show you guys a quick example of that. Remember how the way that this works is it outputs 2000 bundles and then it goes through every bundle, generates an icebreaker and then updates the row? Well if I run this, just think about how long it takes to do one run. That was maybe three seconds, that was maybe another two seconds, maybe another two seconds. If I have 2000 elements times two seconds each, 4000 divided by 60, that's 4000 seconds turned into minutes. This scenario is going to take me 66 minutes in order to finish. So it's actually a little too much for me. Like if you think about it, if I were to try and run this all in one big batch, this wouldn't work. This would time out halfway through, it would break basically, and then I'd be forced to know that it broke and then go back into the scenario settings and then run it again. Or I just have to create some sort of error handling route that notices when the sheet is not fully updated and then does something else. To me, that sounds like kind of a pain in the ass. So this unexpected limitation is very pervasive and a lot of people struggle with it. And Over the course of the next few minutes, I'm going to show you guys how to solve this through two ways. The first is, I'm not going to show you the second one, but I'm going to talk about the second one. But the first solution is to split up a scenario into multiple different scenarios, which reduces the dependency on just one and then reduces what's called the asynchronicity of it. It reduces everything happening simultaneously in one scenario or one flow. For instance, instead of calling an AI module in your flow, you can do an HTTP request. to another scenario that has that AI module in it, and then it instantly resolves. In this way, you could basically run through all 4,000 of those super quickly, and then you can just queue them up into individual module rooms. It'll consume essentially the same number of operations. You're just not going to have to deal with that bullshit that I was showing you guys earlier. So let me show you what this actually looks like in practice. I have a scenario here, NSM podcast campaign. What I'm going to do is I'm just going to split this into one and then two. So I'm just going to open up another scenario here. Let's create a new one. Just going to call this number two. What I'm going to do is in the first one, I'm just going to, oh, actually, if you think about it, this should be my first one. This is actually the second one. I'm just going to copy over this Google sheet, stick it over here in the first one. You can literally just copy modules from one scenario to the other with no problems. And then what I'm going to do is for every record that gets searched, I'm just going to do an HTTP request. What I'm going to do in the HTTP request is I'm going to include all of the data that I care about. So this is a lot of data. I'm not actually going to go through every single one, but I'm just going to show you guys some quick examples using, I don't know, let's do three records or three columns. The first thing of data I'm going to do is I'm going to do row number, and I'm going to do the second thing I'm going to do is I'll do a full name. So we'll go full name and then I'll output full name. And the third thing I'm going to do is I'll go email and then I'll output email. Okay, that looks pretty good to me. And what I'm going to do is I'm going to send this from scenario number one to scenario number two. So the way that I need to catch this in scenario number two is using a webhook. I'll just call this email enrichment example for YouTube. Then I'm going to copy this address and then I'm going to go back here and then paste this. Now what I need to do in order to get my request sent, I need to use a post request. Post requests allow you to use request content, get requests. They only allow you to use this query string, which is not what we want. Okay, great. So now what I'm going to do is I'm just going to run this module just so I can get the data. And then I'm going to, right now the sheet is going to list a million or 10,000 or something results. I just want to list one. So just as a quick test, I'm going to run this. I'm going to send it over here. And then on my backend on scenario number two, you'll see that I caught a row number, a full name, and then an email address. Pretty sweet, right? Okay, great. So actually, I guess my enrichment is going to need more than that, won't it? Yeah, probably. Let's see what sort of variables I need for the enrichment. Full name, company name, title, summary, industry, keywords. Okay, that's kind of annoying, but you know what? We can totally send all these. It's no problem. So I'm actually going to update this and we're actually going to send the round number, full name, company name, title, headline, industry. keywords and then personal location awesome so we can actually send all this data here and then what i'm going to do is i'm just going to update all of these well actually let's just um let's let this run one more time okay so i'm going to run once looks like we're getting a bad request bad control character and string literal and json position 243 let me show you guys how i would deal with this actually i would read through the request content and just see what the problem is here I'm just going to copy this now. And then I paste this into a Jason formatter over here. Then I would format beautify. It looks like I'm getting an error here because there's an additional new line. So basically what we need to do in order to make this request work is we just need to strip all the, uh, strip all the bullshit characters that are being sent in the Jason. So we can't actually have these new lines here. So as annoying as it is, we have to go through, um, we could add a, you know, we could do. we could add another set variables module here. The set variables module would include this, and then what we do is we'd replace all of these new line characters from the set variables module. Inside of this we'd replace all new line characters and we just do i don't know let's just do like a space or something instead of the new line send said request uh we still have some problem here where is this problem coming from oh no scenario my bad it's because no scenario is listening for this right so we just have to run this on this end and then run still getting a bad control character why Let's go back here, format this. Weird. It might be like a tab character or something, honestly. Not entirely sure what the issue is with said tab character, but this just takes me through something else. I'm just going to go through basically all of these characters. We'll go replace new line with the space, and then we'll replace a tab with a space. and then I will run this puppy again and then run this puppy and it looks like it's sort of working which is nice. We are doing what we wanted to do. Actually it looks like it's fine when I paste it in so I wonder if it has something to do with uh sorry what scenario are we at here? Oh weird no we're actually getting the request here. It looks like it's actually being sent which is nice so I don't know why exactly we're getting like a 400. It's kind of odd, strange. Oh, sorry, sorry. I'm silly. What you need to do is you need to have a webhook response here. You need to return 200 and that's going to fix this. Sorry, when you're calling in between scenarios like this in make.com, you need to have some sort of response that provides a 200. Otherwise it's just going to automatically respond with a 400 request. Oops. Sorry, I just realized I sent like a million requests, didn't I? Yeah, we got to make this one. Okay, finally, I'm going to click run. Here, I've changed value at all states as errors, except for 2x and 3x as a no, that's fine. And now I'm going to click run once we should only send one request. Awesome, we sent the request, we got the status code 200. And now we have the data. Perfect. So now I'm just going to plug this into this backend scenario. I do this sort of Usually a lot of the time, just to be clear, like the logic that you are doing will be correct. There's just some sort of syntactical issue, whether it's the JSON formatting, whether it's, you know, you're not fully understanding some of the quirks or tweaks that you have to make to a scenario in order to have the make.com thing work. So don't like sweat it too much. Don't think that it's personal or anything like that. It's not. Most of the time, it's just like a little platform distance difference. I don't really allow stuff like this to slow me down these days. I don't really allow stuff like this to like destroy my confidence because basically every programmer on planet earth goes through the same shit to be honest Anyway, now that I have the row number in this, I can map the second webhook. I have the personalization, the icebreaker, all is good. And then I have sleep. Awesome. So now with all that done, let me actually show you how this would look like. Instead of me doing 4,000 seconds, I'm just going to send 100 requests. And I'm going to zoom out of this. And let's just see. We can finish all of these requests basically instantly. What's happening on this end? Well, oh, this is off. My bad. Right. Let me just turn that puppy on. All right. We're going to process old data. And what happens when you process the old data? Just going to jump in here one more time. You're just going to see a bunch of the executions are now running as we speak, which is nice. And so now instead of us having to process these like all in one scenario, you just process these one at a time. You are getting some webhook response issues here just because this is only going to work when. You send the request then catch them simultaneously. There's a little bit of a gap there, which is why the responses aren't happening. So why don't we, I really want to show you guys how this actually works in practice. So let's just take this down from 100 to 25, same difference. And then let me run this one more time. And now you'll see that all of these are successful because we're running them simultaneously. Basically this end is expecting a webhook response. So it gets that webhook response instantly. Um, yeah, so that is problem number five, I would say very quick and easy way to solve it. It's just by splitting a web hook, uh, sorry, splitting a scenario into two with web hooks. I definitely watch for, you know, Jason issues. Anytime you're sending or receiving data through Jason, you do have to format it specifically in the right way. As you saw back there, I had a little bit of issue massaging the data and getting it in the format that I want, just because sometimes there's additional new lines. Sometimes there's some additional characters that are unsupported. If you want to get a list of all of the unsupported characters, just check out like unsupported characters in JSON. You'll find that there are some curly bastard quotes, which kind of screw with you sometimes. They're like smart quotes and sometimes like various word editors and stuff like that will replace normal quotes with these. Like tab characters are unsupported. Certain, you know, strings in like Arabic or whatever are not necessarily supported in JSON just because when JSON was developed, people weren't really anticipating that they would need to. But yeah, that's that. The second solution is Very similar in nature, but essentially instead of having to wait for the request to finish in the main thread, what you do is you just fire it off to some other place with what's called a callback URL, and then the server will process whatever it needs to process. And then when it's done, it'll just request your webhook, the second half. So this is pretty similar to what I just did. The scenario just returns an auto okay, basically immediately, just like we returned the 200. I think if we wanted to be smarter about it, the status code that we should have returned would be a 201, which stands for in processing. But anyway, basically the scenario or the module is just going to return an OK. And then that's going to be sent off to a server. And then when it's done, it's going to send it back to you. So let me show you a quick example using an API that I use pretty often, one called Any Mail Finder. This is what allows us to very quickly and easily enrich email addresses. And one of these webhook URLs is, or one of the ways you can modify the webhook URL is with a callback. So basically to use webhooks, make a request to any of our endpoints, and then just add a header called x-webhook-url with the URL you want us to send the request to. Basically what you do is you send a request like this, just in make.com. So you do this URL, you do this header, and then you do this as the request body and be a post. And then the second that it gets accepted, you'd receive a 202, which just, again, makes it so that... that make.com doesn't have to spend any more time processing this. And then when you get the result back from the API, I don't know if there's an example of what that would look like. Yeah, it'd be something like this. You'd get an example saying, hey, yeah, the validation was correct. Here's an example of the email address, something like that. And so because now we're not doing the processing inside of make.com, we're sort of offsourcing or outsourcing some of that processing to another server. We don't actually have to wait for that. And we can just run through all of the records in a big bulk. run, um, just at once and not have to wait 40 minutes or whatnot. So I hope you guys appreciated the video. I had a lot of fun putting it together for you. I know that there were some bumps there at the end, especially with the, um, the Jason stuff, but yeah, you know, I've made a ton of money with my deck. I should really tabulate it. I wonder if I'm at $2 million now I might be, uh, and as much as these limitations have certainly bothered me over the course of the last few years, getting up and running with the platform and learning how the platform works, understanding its, its limits and constraints. I still think Make.com is like the best no-code tool out there simply because it allows you to build things so damn quickly and build things that actually improve the revenue. or savings of the company that you're building these things for that. There's just, there's no other system that compares. Typically you're sort of faced to make a trade-off between like the, the rigor and robustness of a system. And then how quickly you can whip like high ROI shit together and make.com is very much like not super robust or rigid, but it allows you to like really whip high ROI shit fast. And that's typically what I care about. I think that's what a lot of people in the future are going to care about too. Just given that with it. with artificial intelligence and with all of these tools, we basically have, um, you know, like we're pretty much, we're soon going to have an infrastructure or an ecosystem where you can just have an idea for a flow. And then it doesn't matter what your level of technical ability is. You'll just be able to either drag and drop a no code thing or write a couple of, um, words to an artificial intelligence, and then it'll be able to do it for you. So yeah, I think make.com really allows you to focus on the things that are important. And these limitations are just, you know, little programming quirks that the developers have yet to fix. If you guys have any questions about any of the limitations that I mentioned in this video, just drop them down below. I really appreciate all your guys'positive feedback and all the ideas that I'm getting. If you guys want me to record a video on something, feel free to drop that too. I recorded this video specifically because somebody asked me to cover all the limitations in Make. So good way of giving back and good way of, I think, listening to my audience as well. Otherwise, if you guys could do me a big solid, if you haven't already signed up to Maker School or Make Money with Make, and this is something that you're considering, if you want to learn how to grow a successful automation business and really crush it in this industry, get your first couple of customers, definitely check those out. They're my two school communities. You can head over to school, just type in make money with maker maker school, or you can just scroll through the bio description at the bottom of this video to find it for yourself. Like, comment, subscribe, do all that fun stuff. I'll catch you on the next video. Thanks so much.

So I see these problems all the time in my own make.com communities. I see them on YouTube and I see them on the wider web when I'm picking up a new project or helping coach somebody through a problem. In this video, I'm going to run you through everything you need to know in order to identify these problems and then solve them.

So I got a little cheat sheet set up here just to add some more value. We're going to be using this cheat sheet as the source just to keep us organized. But I want you to know that if any point in time you find yourself not remembering what I talked about here, you're not entirely sure how to overcome these limitations, just click the link below, pin it, bookmark it, just have it somewhere with you.

I include not only the problem, but I also include multiple ways to solve the problem. And what we're going to be doing now is we're just going to be going through each and every one of them. So the first major limitation in make.com is that there are no built-in delays greater than five minutes.

What do I mean by this? Well, I have a little scenario open here, okay? And pretend just for the purposes of this example that this trigger is something in your business. It's like a HubSpot field being updated. It's a new form entry coming in.

It's a new email that you've watched. And we just want to do something with this, but we don't want to do it right away. What we want to do is we want to wait. We want to wait exactly one hour. How would you solve this in make.com?

Like actually stop for a second. And if you have any experience with make, just ask yourself, how would I solve this problem in make.com? It'll make the rest of this material stick more.

Well, what many people are probably going to think of is, well, there has to be some built-in way to do this, right? And they'd be sort of correct. There's a sleep module that delays an execution for a specified amount of time. So they might drag and drop a sleep module. They click on it and they try and ramp up the delay.

It says the number of seconds for just scenario execution will be suspended. Okay. How many seconds is it? One hour, 3,600. Click that.

Oh no. The value is too big. The maximum value is only 300. Well, if we convert 300 seconds to minutes, that means that the maximum delay that you can actually achieve with this is only five minutes. Okay.

So your next logical step is probably, well, if I can only do this for five minutes and I want to wait an hour, why don't I just create a bunch of these? And then I'll just chain them all together. I'll do 12 in total. And then I'll wait five minutes, five minutes, five minutes, all the way forward. Well, that's another unfortunate reality that you can't do.

and make.com because scenario timeouts are 40 minutes. And because of that, if you try and execute a scenario that's longer than 40 minutes, I think they have a five minute grace period or something. So it might actually be 45. But if you try and execute a scenario that's longer than 40 or 45 minutes, it'll just time out and it'll break. So you're going to do nothing with your flow. So how would you actually solve this problem?

Well, what I'm going to be doing is I'm just going to try and solve the more general case, which is how do you do any delays longer than five minutes? And I'll cover three scenarios. The first is how to get up to about 40 minutes or so.

The second is how to get up to one day. And then the third is how to get up to like an infinite variable amount of time. Let's say you want to send an email in the year 2029 for some reason.

Well, I'm going to show you how to do that using a pretty straightforward approach. Okay, so solution one is just use multiple sleep modules up to 40 minutes. So that's that's pretty straightforward, right?

It's basically what I just did. If I just paste here, and by the way, I'm pasting by holding command and pressing V, maybe I'll call this something more district descriptive, please. We'll go sleep five minutes.

And then I'm just going to copy this, I don't know, let's say four times or something. And I'm just going to wiggle these a little bit. So they connected the scenario and then I'll click auto align here.

What we've basically done is we now have a flow that when I execute it is going to wait five minutes, wait another five minutes, wait another five minutes, and then wait another five minutes. This is 20 minutes. You can realistically do this up to about 40 minutes or so.

Keep in mind that if you try and do this at exactly the 40 minute mark, you may run into some issues because every time a module executes, It also takes a little bit of time, right? It takes like a fraction of a second. So make.com's timeout is 40 minutes. You might have 40 minutes or yeah, 40 minutes worth of sleeps, but then you might have five seconds worth of scenario execution.

You're actually going to go over that. You might break the scenario. So that's the simplest way to do it. That's probably what the vast majority of people here are thinking. The second way to do it, and one that I personally use all the time, is I use a platform called HookDeck.

Okay. Now, what is HookDeck? HookDeck is basically... in my case, it's, it's free or it's a very low cost way to send a request from make.com to hook deck, have a hook deck, do something with it.

And there are multiple things that you can do with it. You could like wait a certain amount of time. You could delay a request.

You could filter a request based on parameters. You could run a function on the request, right? There's a lot of stuff you could do.

And then after the specified amount of time, hook deck can just send it over to your make.com scenario. Again, in this case, it'd be a different scenario and then do the thing that you wanted to do. So the really cool part about this, and I'm not sponsored by HookDeck at all or anything, just to be entirely clear, I just love using HookDeck and use it for a lot of my flows. The really cool part about this is this allows you to queue requests up to one day. And this is what I want to say, probably 80% of all delay use cases will fall under.

So basically, in order to be, you know, 80% good for all of your delay needs in the future, you basically only need to know solution one and solution two. But let me actually run you through what this looks like. Now, obviously, first, you have to make an account in HookDeck.

You have to set everything up and, I don't know, you know, verify your username and password and shit. After you're done, just go over to connections and click on this little connection button. And this is where you're going to set up the logic for your hook deck flow.

Now remember, hook deck is just like an intermediary. So you need to send something from make.com over to hook deck and hook deck is going to catch that just like a web hook. And then it's going to do whatever you want with it, like wait a day, do some filtering function, whatnot.

And then it's going to send it back to make.com. That means that we need something that sends a request to hook deck. And then we also need something that watches for a, um, like a web hook from hook deck as well. Uh, so what I'm gonna do is I'm gonna create a new source. We're just going to call this example source for YouTube.

Let's go delay source. And I think the popo is coming because this video is fire. I'm going to get shadow ban for my shitty jokes. And then we need to define an event destination as well. Um, so what I'm going to do here is I'm just going to say example, delay destination for YouTube.

And you'll see down here, it says endpoint URL. Well, this is where we actually need to set up a scenario that does the thing that we want to do. So in this scenario, for instance, we have a trigger, right? And then we have the action, which is the sending of an email.

What we need to do in order to make this work is we'd actually have to take the trigger and we'd have to make the trigger one side of the scenario. Then we'd have to make the email part another side of the scenario. So I'm actually going to have to create a new one. So why don't I go like 1A, no delays.

And then over here, I'll just make a new one and I'll call it 1B, no delays. And what we need to do at the beginning is we need to send this via HTTP request over to HookDeck. Okay.

And we'll fill in the URL that we're sending to in a second. And then on the back end, what we need to do is we need to catch that request with a webhook. So I can write the word webhook correctly. And then we actually need to create and then copy the address to the clipboard. And we need to paste this down here.

This is going to be the end point. Okay. So we're going to have source. Source is going to be called example delay for YouTube.

That's going to be our first scenario, right? 1A. Then we're going to send it over to HookDuck, catch it. HookDuck's going to do some shit with it, and then it's going to send it over to this endpoint. That's sort of like the logic, the way that we've set it up so far.

Okay, and now is the important part, which is where we define our connection rules. There are four main connection rules with HookDuck. There's transform, filter, delay, and retry.

All these are pretty cool, not going to lie. I'll walk you through each of them. Transform allows you to do something to the data that comes in. Basically, you can actually write your own function.

and then you can take the data, modify it with something, and then you can spit it out. So that's pretty sweet. Obviously you need a little bit of coding knowledge in order to really be able to take advantage of this. I like using this function a lot because it's just a quick and easy way to do things that make.com struggles with inherently like string processing and stuff. And then it allows you to save a lot of operations because you're technically doing this inside of another platform.

And then you just get the finished result in make. Um, you can use Amazon web services for this as well. Uh, the next is filter. So same sort of idea. You basically have some, um, I mean I'm not entirely sure of the syntax, I personally don't use this, but you can filter the event so that it has to have like a key and then a value equal to something.

This is a little bit more nuanced of a requirement. The third is delay which is obviously what we want. So we just click delay, we can delay this request for one second, or you can even delay this request for a day if you wanted to.

You'll notice if you go two days can't be over 24 hours so you do have to max it out at one day. I think HookDuck may be including some functionality that allows you to delay longer. than a day at some point.

I don't know if maybe you need a premium account for this or how that works. And then the last is retry, which is where you can retry every certain amount of time. Anytime you get an error code from the endpoint that you're sending to. So again, a little bit more complicated, but if we try and just solve the simplest one, which is to delay, and then instead of one day here, right, I don't actually just want to wait a whole day because I want to show you guys what the request looks like.

So I'm just going to click a second for now, but keep in mind, if you were to actually try and do this, you'd want to do this for a whole day. I'm just going to name. the connection here and then we'll click create and now what we're going to do is we're going to use this url to receive your requests from example delay for youtube valid request this url will be sent to your destination example delay destination for youtube and hook deck will reply immediately with an http 200 so i'm actually going to copy this now then i'm going to go back to our first scenario which is 1a i'm going to paste it in then the only thing you need to keep in mind with hook deck is you need to do a post request to this url um and you can send whatever the hell you want. Like if you think about it, what we want to do is we actually want to send the data from the previous step because we want to do something with it right so in my case i have an email message equal to hey how's it going that's actually what i want to send so i'm just going to create my own json here i'm going to call it like email message and then i'm actually going to paste this in okay and now what i'm going to do is i'm just going to run this once it's going to get the data from the trigger with the email message hey how's it going and then it's going to send it via http request as you see here the url i'm sending to is this hook deck Basically, I'm sending it to a webhook listener.

And then the request content is email message. Hey, how's it going? And you can see that it's saying status success message request handled by hook deck, blah, blah, blah, blah.

So clearly something is happening here. Something is good. Now you notice that you see connection was created. We actually sent the request and then we have a 400 error code.

The reason why is because I didn't actually set up the other end of my scenario here. I actually didn't finish what I wanted to do. Let me just copy this, paste this email in, and then I'll delete this.

Again, what we want to do is we want to catch it on the other side, right? I just forgot about that. And then what I'm going to do is I'll just go to dot email message because I want to grab the email message from that second webhook and I want to send it out via email.

And let's just try this puppy one more time. So I'm going to send this, just got sent over to hook deck. One second later, it fell into the second batch here and then it sent it over through email to the email address that I had specified.

The email address that I had specified was just naked left click.ai saying, Hey, how's it going? So So again, I did this in one second because I just wanted to show you guys a quick example of how this works. Ideally, you would do this any time period up to a day.

This is one of the quickest and easiest ways to set up a delay time yourself. Using HookDeck, you're basically just swapping this as like a sleep module you can think of it as. So that is solution number two.

Solution number three is a little bit more complicated, but this is like the general solution. This is the thing that allows you to deal with any instance of the scheduling or delay problem. however long in the future it may be. And with this, what you do is you create a request spreadsheet and then you just pull it repeatedly. And I'll talk a little bit in the future about why pulling isn't very good.

And I'll show you some ways that you could eliminate pulling. That's another unexpected limitation to make.com. Um, but this is still a pretty solid way to deal with the delay problem. Let me run you guys through what I mean by this.

Okay. So let's say, you know, our previous example, what did we want to do? We wanted to send an email, um, and we wanted the email to include an email message.

Hey, how's it going? Let's say instead of this super simplistic example, what we actually have is we have like the email that we want to send. And we also have like a date that we want to schedule it at. And let's just hypothetically say, right, it's December the 3rd, 1137 a.m. right now.

Let's say I want to do this on like December the 4th or something like that. Let's just go December 4th, 2024. This would be a simpler example. I'll just show you the date. So actually, I want to wait a whole day to send this tomorrow. Let me show you guys how you'd set this up.

The first thing you need to do is you need to go into some database. I'm going to use Google Sheets in this instance, simplest thing that you can do. And I'm just going to call this, why don't we do like email scheduling database.

Now what you do is you make a column for the thing that you want to send. In my case, this would be email message. Then you also make a column for the date that you want to send it.

So this would be date scheduled. Awesome. So we have our two columns here.

This is going to be the database that we're going to be using to schedule requests. and then execute on those requests. And then you still need two scenarios here. So we need a 1A, we need a 1B.

What 1A is going to do is 1A is going to take the data from our trigger, which could be a form, it could be a HubSpot thing, it could be anything you want. And then the first step is it's going to send this over to the Google Sheet, it's going to add it. So let me see email scheduling database, sheet name, we only have sheet one.

The table does contain headers. It has that email message and date scheduled. We're just going to put email message here and then date scheduled.

Okay. So I'm just going to run this once. It's going to send this over to our Google sheets database, right? And now we sort of have, um, we have the scheduled message. Now on the one B scenario side of things, what we have to do is we have to set up a Google sheet and we have to search the rows using the search rows module.

So let me just hook all this stuff up to the right Google Sheet. This one was called Email Scheduling Database. Just to remember, we're going to be looking for spreadsheet equal to Email Scheduling Database.

Perfect. Sheet names is going to be Sheet 1. It is going to contain the headers, right? And then let's just return one response to start. The reason I get this red bubble every so often is just because when you go a little too fast, it tends not to work.

Okay, so great. So we just ran this. And as you can see, we have an email message equal to, hey, how's it going?

And then we also have a date scheduled for December the 4th, 2024. That's good. That's what we wanted. Now what we need to do is we need to set up logic basically to check the sheet. once a day, and then to only return the records that have a date equal to today. If you think about this logically, right, what's going to happen?

Well, if we run this once a day, every single day, we're going to be running through all the records. And then we're just going to be checking is today's date equal to the date that it was scheduled for? If so, we're going to proceed.

If not, we're not going to proceed. So very simple and easy way of running through this. Let me show you guys what this looks like in practice. The Google Sheets Search Rows module has a filter setup, so we can actually check to see if date scheduled is equal to the current date. Now the way that you do this using make.com, you know, you can't just type in like the now date.

What you have to do is you have to go over to our calendar, we have to go to now, and then what we have to do is we have to format this date so it's in the same format as whatever the date is in like our Google Sheet. So this is going to depend on however you or the trigger puts in the data into. um, Google sheets. So in our case, it says DEC, so that's sort of a three letter month code.

Then it's a space, um, for space 2024. So, uh, there are some IntegraMAT date time tokens here that you can check out that allow you to do this formatting and parsing really easily. In my case, because we're doing December DC, we need an MMM that we need to add a space. Then we need a D that we need another space.

Then we need a year, year, year, year. So I'm going to go over here. I'm going to format this date as MMM.

space D space year, year, year, year. What this is going to do is it's going to grab the current date, which is December the 3rd, and then it's 2024. And then it's just going to format it so that it's MMMDYYYY. And then, you know, this is, this has a schedule for some of the fourth actions.

This isn't actually going to work if I run it. Let's go back to December the 3rd. And let's actually right click, run this module and just see if we get the data. Good. We got it.

And now what we need is we just need to add our email module, which I unfortunately deleted. So let's just create a new one here. It's actually put in the logic and we're going to send this to myself. And then the subject is going to be, this is a scheduled email message with the value of this being email message.

And now I'm going to set the schedule to run every day at let's just say 8 AM. But keep in mind, you can make this as granular or precise as possible. For instance, if you wanted to schedule down to the hour, you could write down the hour as well, and then use like daytime parsing using those tokens I showed you to pull out the hour.

And then you could run this every hour to check and see if this is the same hour. But now, right, if I set up a filter, I just want the total number of bundles to be equal to one. If it's not equal to one, then I don't want it to proceed, right? Found.

Otherwise, we're just gonna be sending a bunch of empty emails. And then, you know, this is going to run daily at 8am. Let's just pretend right now it's daily at 8am. Great. As you can see, we ran through this, we found one record, and now we're sending an email.

And now if I go back to my email, see this is a scheduled email message. This is what I was looking for, which is pretty sweet. So these are the three ways to solve the no delay problem in make.com.

Again, to recap, the first way was just adding a ton of sleep modules. You could get this up to about 40 minutes or so, but you can't go any further than that. The second way was using hook deck, which enabled us to get up to about 24 hours or so using their built-in sort of catch delay and then send feature.

And the third way was building out our own database of requests, adding to them using one scenario and then searching through that scenario or searching through that database, I should say every day with the second scenario until you find something and then connect it to that, uh, that second, uh, action, whatever it is, whether it's send an email or update a record or. I don't know, you can get pretty fancy with it these days. You could even have it like connect with some handwritten letter API and send something out. Whatever the hell you want to do, you can.

So that's unexpected limitation number one. Unexpected limitation number two is of a similar vein, and it's where testing forms takes forever. This is a problem that I've found with a number of no-code platforms, and make.com in particular struggles from this because there's no way to get the data from the form and then just keep it in the no-code builder and then just run it. What this means is if you have like a really intense, a very long form, every time you want to test your flow, you have to fill the whole freaking form out. And I don't think you guys realize exactly what this means to your productivity, but I figured it out pretty quick.

Like if it takes me a minute to run a form every time I want to do a test and I test a flow like 50 times, I'm developing it. I just added at minimum 50 minutes to my flow, like two to my testing or building of that flow. Um, I'll show you guys a couple of quick and easy ways to solve this. For instance, let's say I have a scenario here.

that just watches the responses on a type form. And the type form that I'm filling out is some trial for, you know, working with my company. So it's called the automator trial. First, you have to track your time and clockify. Then you have to do this thing.

Here's a brief. You have to paste a video link. You have to write how much time it took you.

Then you have to send an invoice to us. Let's actually run through and let's, let's just fill this out just as a quick little example. I'm going to run my scenario. So I'm going to run this now. So it's going to be watching for responses from this.

Um, then I have to click this button to click that button. I have to click that button. I have to put some example video. I'm going to just use a Google drive.

I'm going to have to go one Oh four. I'm going to click submit, right? I mean, that took us like 15 seconds that we didn't really need to be spending. And now I have an answer. And, and, you know, every time I want to do something with this, I'm just going to use a set variables module.

Every time I have to do something with this and I want to see what the data is, I basically have to run through this thing again, right? Like I click run once, I just have to wait. And then I have to go into the type form, refresh it, fill the whole form out. It's just, it's mindless.

Not only is it mindless, it also just takes a lot of the time away from the time you could be spending driving actionable results. And then you also kind of forget about what you're doing when you fill out that form so many goddamn times. I'm going to show you guys a better way.

Um, the easiest and simplest way that I've found is just add a sleep module after your type form, and then just add a delay. Um, I'm using 30 seconds now, cause I've found that type forms API starting to take a little while longer to update. And then 99% of the time, whatever form platform you're using, there's usually two modules of interest. There's the watch responses or watch submissions.

And then there's the list submissions, list responses, search responses, search submissions, get submissions, get responses. Sometimes they have different names depending on the platform, but that's generally the two classes. You have something that like watches for new ones, and then you have something else that like just gets all of them. And so in Typeform, for instance, what you have is you have one called list responses here.

So what we're going to do is we're going to watch the responses. We're going to wait a certain amount of time. Then we're going to list the responses.

And I'll show you guys why I'm doing this in this way. It'll make perfect sense to most of you in a second. The form ID we're going to be pulling the data from is going to be the automator trial.

And then the limit is just going to be one. Okay. So look what happens, right?

If I run this once, and now we still have to wait to fill out a form request, and that's going to take forever. It's going to take us 15 seconds every time we want to test. Well, what if now I just unhook this and I just drag this over to list responses. I run it.

It instantly gets the data that I was looking for. So what does this mean? Well, it means that. Later on in the flow all you need to do in order to test your scenario is just connect all of the Variables to this module instead of this module So I'm just gonna say example variable and then anytime you want to test and see how the rest the flow goes you just click Run once it gets the data for you And then you can actually test and see the actual run and then when you're actually done and you're ready to make this flow production All you do is you drag this over to the walk watch responses module, you connect it, and then now you don't need to do anything else.

Your whole scenario is basically production ready. Um, this does take you two extra operations per scenario run, I should say, right? Cause we have this watch response in this sleep that aren't technically necessary.

Um, but because you're getting the data from this scenario or from this module, I should say, uh, you don't actually have to do any of the really annoying swapping. Like imagine if this scenario was like 500 times as long. Just unbelievably long, just so many millions of modules. If you did this the previous approach, or you tried hard coding the data or something, you would have had to go through every subsequent module and you would have to swap out the variables so that instead of calling this one, it called this one. Now you don't have to do any of that anymore, which is pretty sweet.

So that's solution one. Just submit the form once, then use a list responses or search responses or whatever the hell it's called. If you're using something different like jot forms or paper forms, hello forms, and so on and so forth.

The second solution, and this one is a little bit more general of a solution. It still takes you a fair amount of time because you do have to do that swapping that I mentioned, but you can, you know, because of this, you can, you could save a fair amount of the bullshit as well. You submit the form once, and then you take the output JSON and stick it in a parse JSON module. And then you just use that to test.

Let me show you guys what I mean. So this is my scenario here, right? So I'm going to pretend that we're back at the very beginning here with this watch responses form. What I'm gonna do is I'm going to go grab a parse JSON module.

And I'll show you guys why I'm adding this right now. But anyway, first we're going to run this. I'm going to go back to my Automator trial. I'm just going to fill out this form. So blah, blah, blah, some more boring stuff and 119 and then submit.

Great. And then notice how over here, top left hand corner, we have a download input bundles, download output bundles. Sorry.

What you want is you want the download output bundles. If you've never used this before, it's extraordinarily powerful because what you can do is you could actually just copy the json that you want and then you could add it to a um parse json module and then you could just instantly get the data for a test input and then just use that to test every output what do i mean i'm just going to copy what i care about which is these mapable answers over here and you do need to wrap this in just a pair of curly braces and then i'm just going to now run this module only and what you can see is we've actually like hard coded a test uh case where we have the key and then the value and it's just the same key and value every time because when we run this we had input json and output json in the watch responses module we just copied all the output json we stuck it in this thing and now we can just continuously run this however long we want essentially and then all downstream modules here i don't know let's say we're connecting to some some hubspot service or something you can just draw the data from the exact same thing that you had before right? The watch responses module.

It's just this time it's like hard coded in the JSON. Bonus points are when you actually do go to update this later and you go to, you know, back to the form and change this, you notice that because the key names are exactly the same, you could still save a fair amount of time by just swapping out the module number. What do I mean by this? Well, um, the way that these variables are represented, they're actually represented in code. If you copy one and then paste into your URL bar, you see how it says this 16 dot mappable underscore answers, period space, and then the key, the key name.

Well, if you just change the 16 for the two, copy this and then paste this back in here, this will actually reference this. And so instead of you having to like go through that drag and drop rigmarole, which I think a lot of no code platforms struggle with, but make.com in particular can be pretty annoying about, you could save yourself a ton of time just by like pasting into the URL bar, changing the number, pasting again, pasting the URL bar, changing the number, pasting again. So quick and easy hack that I've found to solve this for myself. And one thing that I use basically every day to overcome this unexpected limitation.

All right, let's talk about limitation number three, which is errors and executions. What do I mean by this? Well, I'm going to show you guys a quick example.

I have a scenario over here, and it's just sort of a fake scenario. But in the scenario, I have an HTTP request module that calls a URL called leftclick.ai zzzz. Now, there is no website called leftclick.ai zzzz. So when I run this, it's not actually going to complete. It's not actually going to be able to make it to, you know, the rest of the scenario.

And that's actually a problem for us and make.com because a lot of the time, what you want to do is you don't actually just want to end the whole flow. Like anytime I run this thing, it's not going to make it to the second and the third sections. Like, like the second that there's an error, especially in like an HTTP request module, nothing makes it past this.

So like hypothetically, if I want to do one thing, if it's successful, but I want to do another thing, if it's not, what the hell do I actually do? How do I actually make it? Right.

What I'm going to show you is a quick and easy way that you can apply to basically any scenario that has an error in it that you want to route based off of whether or not the error works or not. I mean, that's called using the resume module. It's one of the fewer and littler known error handlers in Make, but the resume module is extraordinarily powerful.

And ever since I learned about the resume module, quite frankly, I've started using it for more or less every flow of mine that has any sort of import. I think when you guys see the value in the resume module, you'll start doing so as well. Okay. So as we see, we keep on getting the service is not reachable connection error. Well, what we want to do hypothetically is we want to go down this route if it succeeds, and then we want to go down this route if it doesn't succeed.

So what I'm going to do is I'm just going to call this success. And then I'm going to call this one here, failure. And you can imagine how we go down success to do something like we're calling, we're calling my website, right? In this case, maybe you're calling some.

website and you would want to extract the data from it and do something cool with it. Maybe you want to use AI to get you the email addresses. Maybe you want to have AI summarize something about it.

Maybe you want to run a regex or a regex, sorry, on the data itself and then run through it top to bottom to do something, parse, whatever. And we just want to be able to go down different routes depending on whether or not there's an error. The solution is just go over here to flow control, type in resume, and then connect resume to this HTTP request module. What resume does is resume will allow you to change. So first of all, it'll continue going down.

Basically it'll say, don't stop this module here. And that'll allow you to change the output. If there's an error. Okay.

So if there is an error, I want the status code to be 400, which I believe it will actually already be 400. And then what I want to do is I want to have routes that check to see the status code. And if status code is equal to 400, it's going to go down this route. Whereas if the status code here is equal to 200, which is just what it returns, if it's successful, it'll go down this route. Now for the second thing, I don't know, I just want to like example data. And instead of adding in the actual HTTP, sorry, HTML, I just want to do like my own HTML.

Just as a quick little example, I don't think there'd actually ever be any use case or scenario in which you'd actually want to do this. But still, let me show you guys what it would look like. Okay, so what we saw there was it instantly failed.

The second that it failed and we got the service is not reachable. We went over here and we replaced the status code with 400. Now we have a status code of 400, which allows us to route down to this second route and then do whatever we wanted with thing B. If hypothetically we didn't call that broken module or broken URL, we called the correct URL. It'll go up this top route.

Oh, and it looks like there's just no, there's no data here, which is why that didn't work. So let's run that one more time. And then instead of going down the failure route, now it's going to go down the top route.

And so in this way, we basically allowed us a much more dynamic application. Our backend is now not super fragile. It's not like the second that something fails, that's it. We need to crash the whole thing.

We can actually control the flow of an error and we can do things with it that enable us to account for these sorts of problems. This is something that I, as I mentioned, did not learn until very, very recently, embarrassingly recently. So I'm not saying that you need to know how to do all of this super fancy error handling in order to make a million plus dollars with bank.com. But you do need to at least conceptually understand that errors end executions and you need to know sort of how to handle them and so on and so forth.

So yeah, that's issue number three, which is a very unexpected limitation. Issue number four is that the default scheduler costs a lot. What do I mean by default scheduler costing a lot? Well, in Make.com, you basically have two ways of getting data and doing shit with it. So on the trigger module, you can either trigger every so often.

So remember how back in our Google Sheets example, we triggered every hour or so, or sorry, every day to check and see whether or not there was a row in our spreadsheet with a date equal to the current date. Well, you can either use some sort of schedule-based trigger, or you can do an instant trigger. And if you think back to our hook deck example, where I was waiting for a request from hook deck, and then the second that I got it, the scenario proceeded, that's sort of like a hook-based example. So The issue in make.com is there are a lot of modules out there that don't actually have the ability to run instantly based off new data. And so they have to do the scheduler.

And the scheduler is actually a lot more expensive than most people think about. I'll give you an example. The default scheduler with make.com, this little scenario here that's just checking my email inbox.

If we click this button, it's going to be 15 minutes. I just want you guys to do the math with me for a second. If you run a scenario every 15 minutes, 15 minutes is four times per hour.

Okay. That's four times 24 times per day. That is 96 times a day.

That's 96 times 30 times per month, which comes out to, I don't know, 2,880. Is that correct? Yeah.

2,880 times per month. Imagine spending 2,880 ops per month on a single scenario. And that's assuming that that scenario, it doesn't have any follow-up operations at all.

We're literally assuming the only thing that triggers there is this first module. That's crazy. If you look at like make.com's pricing, just have them spend a little bit of their ad budget there.

Sorry, make. You'll see that on a monthly plan, it's 1882 per 10,000 ops. That means you're literally spending about a third of this, which is about six freaking dollars just on one scenario to do the scheduling. So it's crazy. You really should not be using the default schedule anytime you can.

I mean, you know, $6 might not mean a lot to you. It certainly doesn't mean a lot to me at this point, but still, I don't want to get in the habit of just like having every scenario I run cost $6 because I have a hundred scenarios, right? If I were to do that, we'd start getting into some pretty shitty territory. So I have a couple of solutions to this.

We're not going to be able to run through every single one, but I will run you guys through the default schedule or costing a lot. And I'm also just going to talk about just everything costing a lot of operations as well. Because it's actually not just the default scheduler that I wanted to cover. It's just like operations in general.

They can cost a lot in make.com. Other platforms aren't necessarily as expensive as make or some of them are more expensive in different ways. Make.com is definitely like the operational cost scaling. So the first and the simplest way to solve like operational issues, particularly with regards to scheduling, is to replace all of your scheduling triggers with a single schedule.

instant triggers instead. Those ones that I was talking about earlier that just wait for an event and then do something with it. So if we go back to our example here, this is probably the number one most commonly used module in email.

It's just a watch emails module. And basically what people will do is they'll say, well, I want to do thing X every time I get an email coming into my, my inbox. Every time somebody, I don't know, um, raises a customer support ticket or something. What I want to do is I want to get that. And then I want to forward it over to somebody in my team.

Sounds pretty cool, right? The issue with the watch emails module, which is the default one in the emails, I guess, class of modules is that it runs based off scheduling. And so two problems here. The first is that you're going to have to wait at most 14 minutes and 59 seconds, basically. Like what if an email comes in immediately after the thing pulls, you basically have to wait another 15 minutes to get it right.

14 minutes, 59 seconds or whatever. And then two, you're just going to be running this four times an hour, which is 20 or now 96 times a day, which is 2,000 times a month. There's a much easier and more elegant way to do this that actually runs instantly.

and doesn't suffer any of those problems. And that's using what's called a mail hook. So instead of constantly pulling my mailbox, instead what a mail hook is, is it is a custom trigger that runs anytime it receives an email address to this string. And as you can see, it's very customized.

Like this is the only email that exists ever. Sorry, every time this instantiates, like it's totally unique email. It's not like you're ever going to have any conflicts or issues with us.

But what you do is instead of watching your email address, you just send all of your customer tickets over to this email address instead. And then I'm just going to run this now. And then the second that. an email makes it over to this mail hook and Google takes, I think, five seconds or so, which is why this isn't like instant instant. It's technically being queued up in Google's server right now, um, before it gets sent out.

But when we receive it, we have all of the same information that we would have had previously. The only difference is we didn't have to wait 50 minutes and then we didn't have to do polling, uh, 2,880 times a month just to get this email. So that's solution number one. There are a variety of these little hacks here.

Um, I just showed you how to do one for email. Another common issue is Google Sheets. A lot of people will do the watch new rows module.

And basically this is similarly only going to run every time we watch or sorry, every 15 minutes or so. It's just going to batch all of the new rows added to a spreadsheet every 15 minutes, which is super inefficient and just not very smart. If we just go to, I don't know, all or something, it's going to run this.

This is the same spreadsheet that I was using earlier as part of the email scheduling example. And you see that, you know, it just pulled in the data that we were looking for, right? But now let's say we want to add another one. Notice how it's not, it's not actually running. We're not actually getting anything.

It's not like it just waits for it. What this is doing is it's basically running a poll every single time I execute this, which again would be 2,880 times a month. Now, if I added another row in here. I would basically have to wait God knows how long in order to receive that data, right? We basically have to wait until the next execution, which would be 15 minutes or so.

I just did it instantly to show you guys. And then I also find anecdotally, this kind of fucks up with my testing quite a bit. If you were to try and like delete a row or whatever, then it'll just forget that you've, sorry, it'll remember that you've been to row three. And then when you add another one, it's not going to notice it. So you can get around that pretty easily in Google Sheets.

You just need to add what's called the watch changes module. I'm not going to run through how to do all of these little optimizations, but the watch changes module is very similar to the watch new rows module. It's just, you have to go into Google sheets and then you have to install an app. So kind of annoying, but a little Chrome extension that you have to do. So this watch changes module is going to be under extensions, add-ons, get add-ons.

So we'd go extensions, add-ons, get add-ons, and then I'd have to go make.com. Or sorry, I believe this had a specific name. Make for Google Sheets. Yeah, they don't do the, they don't actually say make.com in this.

Where are we? And then you have to like add this in here and then connect this and, you know, do a bunch of rigmarole. The point that I'm getting at though is this just solves you having to do that weight. Okay. So that's, that's problem number one, which is a very big problem.

And I think that, you know, probably already saved several thousand dollars in aggregate. The second solution to operationally intensive things. And so, you know, I realize now that I, I said that this was about a default schedule problem.

Really? It's just like the operations problem in general. Default scheduling is like the main reason why though.

The second solution to everything costing a lot of ops is to look into bulk or batch API calls. So for instance, let's say you're doing something with Google sheets. Okay.

And I have a little scenario set up here that does something with this. This is something that I actually just used for a podcast campaign of mine a couple of weeks ago. Basically I have a big list of people over here. and email addresses.

And this is a massive list of all of these people across all of these different industries. Typically the connection between them is that they do podcasts. And what I want to do is I want to send a request over to this spreadsheet. I want to get a record. And then what I want to do is add it to an open AI call that generates an icebreaker for that.

Then I want to do another HTTP request that updates that row. And then I want to wait a little bit. So let's just look at what happens when I execute this.

First, I get all of the people in this sheet, which is a lot of people, several thousand, right? Then I generate an icebreaker, then I update around Google Sheets, and then I sleep. What's really happening here? I'm consuming one operation to get the list.

Then I'm consuming n operations, depending on the size of the list, another n operations, depending on the size of the list, and another n operations, depending on the size of the list. So basically, if I just like math this out, it's 3n plus 1. n just being the number of rows in my spreadsheet, right? Well, I can actually take this from a 3n plus 1, and I could realistically convert this into a n plus 1 instead, which, if you think about it, makes my whole scenario three times more efficient.

The way that I do this, and I've recorded a video on this that I'm going to link in this YouTube video, so just check the top right hand corner of the screen at some point, and you'll have a link to one of my bulk HTTP request modules. where I show you guys how to do a bulk request to Google Sheets. But basically the vast majority of worthwhile APIs, they have like a way that you can add things in bulk as opposed to add things one by one.

Google Sheets is one of them. If you go over here to Google Sheets, you'll see there's bulk add rows and then bulk update rows. There's also a make an API call module, which you can use as well.

I personally use this one to do the bulk row updates because I find that it's a little more reliable. But essentially, instead of having to update the rows like we're doing over here, what you could do is, you know, you could just... aggregate all of the outputs of the GPT-4 module.

Then you could just use this bulk. Oh, I guess we have to select my spreadsheet. So just give me one sec. Let's grab the actual spreadsheet ID here and then connect this.

It doesn't look like we're finding this. I may be connected to the wrong thing. No, I'm not. What is this going to be called?

NSM podcast campaign, right? This would be Apollo Leads Rapidly. Yes, this one right here.

And the sheet name here would be just sheet one. The range would be, would it be like A1 to, I guess, AR2001. And then what you basically need to do is instead of adding just one. record at a time, you actually create your own array where every column in this spreadsheet here is one element of the array. So if I wanted to update this, I'd update this as like Allie.

I have to go back and get their last name, Zewail. I have to do Allie Zewail and so on and so on and so forth. all the way until I make it to the end of the sheet.

And then what I'm basically doing is I'm doing an array of arrays. And because of this now, instead of me doing, you know, I mean, how long was that sheet about 2000 rows, instead of me doing 2000 operations, which would basically consume a fifth of a whole month's worth of operations in a single run, I could just batch this and do them all at once. Now, in order to make this happen, you would need to do some fancy text aggregation stuff, which is what I show in the video. And I'm not going to run into the specifics of it. Basically, you have to make your own, you essentially have to like create your own formula here with the text, and then you have to map over all of the output columns and so on and so forth, and then connect them and turn them into JSON.

But if you are using something like I was showing you here, at any level of frequency, you can usually save several 1000 operations a month, or even several 1000 operations a run, to be honest, just by implementing bulk HTTP requests, such as Google Sheets as a bulk. HTTP request module. You could do bulk add modules and air table. Um, you could do, uh, bulk batch AI updates like open AI is GPT for actually has a batch output. endpoint, which allows you to basically do the same thing.

Instead of feeding it in one at a time, what you do is you get all those one at a times, you batch it into just some giant array, you just send it all there at once, and then wait until it's done. In this specific case, I believe it takes 24 hours or so that you have to wait, which may be a little bit longer, but there are many use cases which people are okay waiting 24 hours. Same thing with Claude, Anthropic has a batch endpoint.

And there's just a lot of ways that you can minimize your operations usage and My point here making this video, specifically talking about unexpected limitation number four, is just point you guys in the right direction here. Know that you don't need to consume, like you don't have to spend $20 every time you run one of these things if you use bulk or batch API calls. Okay, the third thing I want to talk about is basically once I build a flow, I will run through that flow and I'll remove all of the modules that I consider unnecessary.

So let me show you guys a quick little example here just using this scenario. what a lot of people will do, and they'll do this because they want to, you know, like keep track of their data and store where it is, or they just want to make things more easily accessible for them is they'll use the set variables modules very often. And typically what they'll do is they will remap a variable that comes in.

So maybe instead of full name, they call the variable full name with a space instead of this underscore, and then they just map the variable in here. Then maybe we have another one kind of later on that just sets. another variable, maybe it's called like personalization, and then they'll remap something that technically is already present and accessible in make.com.

But they'll do it using the set variables module, just so that like it's a little prettier, it's a little more accessible. This is fine to do when you're actually developing stuff. And don't get me wrong, I do this all the time.

I recommend that people do this during the development stage. The issue is when you push to production, and that just means like when you make a scenario live, you are now paying for two additional operations. Consider that this is in total a six operation flow. So you've essentially just multiplied the number of operations you are going to be spending on this by something like 30%. So an instant way to reduce the number of operations you're spending in a scenario is typically just to go through and remove all of the purple modules.

So typically like the set multiple variables modules, for instance. There are a lot of other ones here that aren't explicitly necessary, switch modules and whatnot, and then just delete all of them. And then instead of using the variables from the purple modules, just jump in and then remap them. So you're pulling directly from the modules that output those variables.

So instead of me using that, like, I don't know, let's go over here actually. Instead of me using that other icebreaker, I would just use the one that comes directly out of my generate icebreaker module in GPT. This is just a little minor optimization.

You're probably not going to be able to save, like I'd consider solution two here. Solution one and solution two, they're capable of saving you like a hundred times as many operations. This is probably capable of saving you like 30% as many operations, which is still fine. Okay.

And the last thing I want to talk about is just the difference between iterating over multiple bundles versus using arrays wherever possible. So, um, as opposed to, you know, and we tie that, I'm going to tie this in a solution too, as opposed to us having to iterate through a list of a thousand records, and then one by one, send those records off to someplace. What you can typically do is you can just aggregate them all into an array using the text aggregator or some sort of array aggregator. And now you're only really working on a single element because in make.com, like a single bundle can contain an array that contains hundreds of thousands of elements.

So in order to do this, you need to understand array aggregators, which is sort of like a special class of function. Not a lot of people fully understand them yet. They're probably one of the most widely misunderstood things in make.com.

I've recorded multiple videos on iterators and aggregators and how they work. And I'm not necessarily going to recap them all now. I just want to show you that basically an aggregator is an inverse iterator, and an iterator is an inverse aggregator. An iterator will take in an array, and it will just split it into multiple bundles.

And then an array aggregator will take in multiple bundles, and it will just convert it into one array. So anytime that you use an iterator, you could use an aggregator to turn that back into an array. And anytime you use an aggregator, you could use an iterator to turn that back into multiple bundles. There are a bunch of modules in make.com that have built-in iterators. anything that returns more than one bundle has a built-in iterator.

As you see, this Google Sheets search rows module has a built-in iterator. It iterates through, you know, 2000 requests. So what I could do is I could actually just aggregate all of these by sticking in the array aggregator next to it, using this as the source module.

And then I get to pick the fields that I want to aggregate, basically. Let's just say I want to aggregate a big list of first names here and, you know, a couple other things. And then if I just unlink the rest of this and run this, Despite the fact that we've outputted, you know, 2000 bundles here, we're not running this array aggregator 2000 times. We fed into it 2000 bundles. But the output of this is a single array.

And that single array is obviously a lot more workable, I would say, on bulk. Even though it has 2000 elements, that single array is a lot more workable in bulk. You could do things like, you know, filter through to find the, to extract only the elements where the first name is Lawrence or something.

And you could do it using maps functions. You could do this using sort functions and so on and so forth. You just don't necessarily have to muck up your monthly operations usage in order to do so. Awesome.

So that is problem number four. Next up, I want to talk about problem number five, and this is alluded to earlier by my sleep module or delay problem. And that's that scenarios will inevitably timeout after 40 minutes. So big problem here flows that iterate over a large amount of data, like from a database, like Google sheets or air table, or ones that use AI or ones that use delays can exceed the 40 minute timeout limit and make.com, which is a problem. So I pulled up this scenario actually to show you guys a quick example of that.

Remember how the way that this works is it outputs 2000 bundles and then it goes through every bundle, generates an icebreaker and then updates the row? Well if I run this, just think about how long it takes to do one run. That was maybe three seconds, that was maybe another two seconds, maybe another two seconds. If I have 2000 elements times two seconds each, 4000 divided by 60, that's 4000 seconds turned into minutes. This scenario is going to take me 66 minutes in order to finish.

So it's actually a little too much for me. Like if you think about it, if I were to try and run this all in one big batch, this wouldn't work. This would time out halfway through, it would break basically, and then I'd be forced to know that it broke and then go back into the scenario settings and then run it again. Or I just have to create some sort of error handling route that notices when the sheet is not fully updated and then does something else.

To me, that sounds like kind of a pain in the ass. So this unexpected limitation is very pervasive and a lot of people struggle with it. And Over the course of the next few minutes, I'm going to show you guys how to solve this through two ways.

The first is, I'm not going to show you the second one, but I'm going to talk about the second one. But the first solution is to split up a scenario into multiple different scenarios, which reduces the dependency on just one and then reduces what's called the asynchronicity of it. It reduces everything happening simultaneously in one scenario or one flow. For instance, instead of calling an AI module in your flow, you can do an HTTP request.

to another scenario that has that AI module in it, and then it instantly resolves. In this way, you could basically run through all 4,000 of those super quickly, and then you can just queue them up into individual module rooms. It'll consume essentially the same number of operations.

You're just not going to have to deal with that bullshit that I was showing you guys earlier. So let me show you what this actually looks like in practice. I have a scenario here, NSM podcast campaign.

What I'm going to do is I'm just going to split this into one and then two. So I'm just going to open up another scenario here. Let's create a new one. Just going to call this number two. What I'm going to do is in the first one, I'm just going to, oh, actually, if you think about it, this should be my first one.

This is actually the second one. I'm just going to copy over this Google sheet, stick it over here in the first one. You can literally just copy modules from one scenario to the other with no problems.

And then what I'm going to do is for every record that gets searched, I'm just going to do an HTTP request. What I'm going to do in the HTTP request is I'm going to include all of the data that I care about. So this is a lot of data. I'm not actually going to go through every single one, but I'm just going to show you guys some quick examples using, I don't know, let's do three records or three columns. The first thing of data I'm going to do is I'm going to do row number, and I'm going to do the second thing I'm going to do is I'll do a full name.

So we'll go full name and then I'll output full name. And the third thing I'm going to do is I'll go email and then I'll output email. Okay, that looks pretty good to me. And what I'm going to do is I'm going to send this from scenario number one to scenario number two.

So the way that I need to catch this in scenario number two is using a webhook. I'll just call this email enrichment example for YouTube. Then I'm going to copy this address and then I'm going to go back here and then paste this. Now what I need to do in order to get my request sent, I need to use a post request.

Post requests allow you to use request content, get requests. They only allow you to use this query string, which is not what we want. Okay, great.

So now what I'm going to do is I'm just going to run this module just so I can get the data. And then I'm going to, right now the sheet is going to list a million or 10,000 or something results. I just want to list one. So just as a quick test, I'm going to run this. I'm going to send it over here.

And then on my backend on scenario number two, you'll see that I caught a row number, a full name, and then an email address. Pretty sweet, right? Okay, great. So actually, I guess my enrichment is going to need more than that, won't it?

Yeah, probably. Let's see what sort of variables I need for the enrichment. Full name, company name, title, summary, industry, keywords. Okay, that's kind of annoying, but you know what? We can totally send all these.

It's no problem. So I'm actually going to update this and we're actually going to send the round number, full name, company name, title, headline, industry. keywords and then personal location awesome so we can actually send all this data here and then what i'm going to do is i'm just going to update all of these well actually let's just um let's let this run one more time okay so i'm going to run once looks like we're getting a bad request bad control character and string literal and json position 243 let me show you guys how i would deal with this actually i would read through the request content and just see what the problem is here I'm just going to copy this now. And then I paste this into a Jason formatter over here. Then I would format beautify.

It looks like I'm getting an error here because there's an additional new line. So basically what we need to do in order to make this request work is we just need to strip all the, uh, strip all the bullshit characters that are being sent in the Jason. So we can't actually have these new lines here. So as annoying as it is, we have to go through, um, we could add a, you know, we could do. we could add another set variables module here.

The set variables module would include this, and then what we do is we'd replace all of these new line characters from the set variables module. Inside of this we'd replace all new line characters and we just do i don't know let's just do like a space or something instead of the new line send said request uh we still have some problem here where is this problem coming from oh no scenario my bad it's because no scenario is listening for this right so we just have to run this on this end and then run still getting a bad control character why Let's go back here, format this. Weird.

It might be like a tab character or something, honestly. Not entirely sure what the issue is with said tab character, but this just takes me through something else. I'm just going to go through basically all of these characters.

We'll go replace new line with the space, and then we'll replace a tab with a space. and then I will run this puppy again and then run this puppy and it looks like it's sort of working which is nice. We are doing what we wanted to do. Actually it looks like it's fine when I paste it in so I wonder if it has something to do with uh sorry what scenario are we at here? Oh weird no we're actually getting the request here.

It looks like it's actually being sent which is nice so I don't know why exactly we're getting like a 400. It's kind of odd, strange. Oh, sorry, sorry. I'm silly. What you need to do is you need to have a webhook response here. You need to return 200 and that's going to fix this.

Sorry, when you're calling in between scenarios like this in make.com, you need to have some sort of response that provides a 200. Otherwise it's just going to automatically respond with a 400 request. Oops. Sorry, I just realized I sent like a million requests, didn't I?

Yeah, we got to make this one. Okay, finally, I'm going to click run. Here, I've changed value at all states as errors, except for 2x and 3x as a no, that's fine.

And now I'm going to click run once we should only send one request. Awesome, we sent the request, we got the status code 200. And now we have the data. Perfect. So now I'm just going to plug this into this backend scenario.

I do this sort of Usually a lot of the time, just to be clear, like the logic that you are doing will be correct. There's just some sort of syntactical issue, whether it's the JSON formatting, whether it's, you know, you're not fully understanding some of the quirks or tweaks that you have to make to a scenario in order to have the make.com thing work. So don't like sweat it too much. Don't think that it's personal or anything like that.

It's not. Most of the time, it's just like a little platform distance difference. I don't really allow stuff like this to slow me down these days.

I don't really allow stuff like this to like destroy my confidence because basically every programmer on planet earth goes through the same shit to be honest Anyway, now that I have the row number in this, I can map the second webhook. I have the personalization, the icebreaker, all is good. And then I have sleep.

Awesome. So now with all that done, let me actually show you how this would look like. Instead of me doing 4,000 seconds, I'm just going to send 100 requests. And I'm going to zoom out of this. And let's just see.

We can finish all of these requests basically instantly. What's happening on this end? Well, oh, this is off.

My bad. Right. Let me just turn that puppy on.

All right. We're going to process old data. And what happens when you process the old data?

Just going to jump in here one more time. You're just going to see a bunch of the executions are now running as we speak, which is nice. And so now instead of us having to process these like all in one scenario, you just process these one at a time. You are getting some webhook response issues here just because this is only going to work when. You send the request then catch them simultaneously.

There's a little bit of a gap there, which is why the responses aren't happening. So why don't we, I really want to show you guys how this actually works in practice. So let's just take this down from 100 to 25, same difference. And then let me run this one more time.

And now you'll see that all of these are successful because we're running them simultaneously. Basically this end is expecting a webhook response. So it gets that webhook response instantly.

Um, yeah, so that is problem number five, I would say very quick and easy way to solve it. It's just by splitting a web hook, uh, sorry, splitting a scenario into two with web hooks. I definitely watch for, you know, Jason issues.

Anytime you're sending or receiving data through Jason, you do have to format it specifically in the right way. As you saw back there, I had a little bit of issue massaging the data and getting it in the format that I want, just because sometimes there's additional new lines. Sometimes there's some additional characters that are unsupported. If you want to get a list of all of the unsupported characters, just check out like unsupported characters in JSON. You'll find that there are some curly bastard quotes, which kind of screw with you sometimes.

They're like smart quotes and sometimes like various word editors and stuff like that will replace normal quotes with these. Like tab characters are unsupported. Certain, you know, strings in like Arabic or whatever are not necessarily supported in JSON just because when JSON was developed, people weren't really anticipating that they would need to. But yeah, that's that. The second solution is Very similar in nature, but essentially instead of having to wait for the request to finish in the main thread, what you do is you just fire it off to some other place with what's called a callback URL, and then the server will process whatever it needs to process.

And then when it's done, it'll just request your webhook, the second half. So this is pretty similar to what I just did. The scenario just returns an auto okay, basically immediately, just like we returned the 200. I think if we wanted to be smarter about it, the status code that we should have returned would be a 201, which stands for in processing.

But anyway, basically the scenario or the module is just going to return an OK. And then that's going to be sent off to a server. And then when it's done, it's going to send it back to you. So let me show you a quick example using an API that I use pretty often, one called Any Mail Finder. This is what allows us to very quickly and easily enrich email addresses.

And one of these webhook URLs is, or one of the ways you can modify the webhook URL is with a callback. So basically to use webhooks, make a request to any of our endpoints, and then just add a header called x-webhook-url with the URL you want us to send the request to. Basically what you do is you send a request like this, just in make.com. So you do this URL, you do this header, and then you do this as the request body and be a post.

And then the second that it gets accepted, you'd receive a 202, which just, again, makes it so that... that make.com doesn't have to spend any more time processing this. And then when you get the result back from the API, I don't know if there's an example of what that would look like.

Yeah, it'd be something like this. You'd get an example saying, hey, yeah, the validation was correct. Here's an example of the email address, something like that.

And so because now we're not doing the processing inside of make.com, we're sort of offsourcing or outsourcing some of that processing to another server. We don't actually have to wait for that. And we can just run through all of the records in a big bulk. run, um, just at once and not have to wait 40 minutes or whatnot. So I hope you guys appreciated the video.

I had a lot of fun putting it together for you. I know that there were some bumps there at the end, especially with the, um, the Jason stuff, but yeah, you know, I've made a ton of money with my deck. I should really tabulate it.

I wonder if I'm at $2 million now I might be, uh, and as much as these limitations have certainly bothered me over the course of the last few years, getting up and running with the platform and learning how the platform works, understanding its, its limits and constraints. I still think Make.com is like the best no-code tool out there simply because it allows you to build things so damn quickly and build things that actually improve the revenue. or savings of the company that you're building these things for that.

There's just, there's no other system that compares. Typically you're sort of faced to make a trade-off between like the, the rigor and robustness of a system. And then how quickly you can whip like high ROI shit together and make.com is very much like not super robust or rigid, but it allows you to like really whip high ROI shit fast.

And that's typically what I care about. I think that's what a lot of people in the future are going to care about too. Just given that with it. with artificial intelligence and with all of these tools, we basically have, um, you know, like we're pretty much, we're soon going to have an infrastructure or an ecosystem where you can just have an idea for a flow. And then it doesn't matter what your level of technical ability is.

You'll just be able to either drag and drop a no code thing or write a couple of, um, words to an artificial intelligence, and then it'll be able to do it for you. So yeah, I think make.com really allows you to focus on the things that are important. And these limitations are just, you know, little programming quirks that the developers have yet to fix.

If you guys have any questions about any of the limitations that I mentioned in this video, just drop them down below. I really appreciate all your guys'positive feedback and all the ideas that I'm getting. If you guys want me to record a video on something, feel free to drop that too. I recorded this video specifically because somebody asked me to cover all the limitations in Make.

So good way of giving back and good way of, I think, listening to my audience as well. Otherwise, if you guys could do me a big solid, if you haven't already signed up to Maker School or Make Money with Make, and this is something that you're considering, if you want to learn how to grow a successful automation business and really crush it in this industry, get your first couple of customers, definitely check those out. They're my two school communities. You can head over to school, just type in make money with maker maker school, or you can just scroll through the bio description at the bottom of this video to find it for yourself.

Like, comment, subscribe, do all that fun stuff. I'll catch you on the next video. Thanks so much.

Transcript for:Overcoming Make.com Platform Limitations

Transcript for:
Overcoming Make.com Platform Limitations