WEBVTT 00:00:00.000 --> 00:00:02.640 Hey, welcome to the deep dive. So if you're using 00:00:02.640 --> 00:00:06.400 NNN for automation, you know it's pretty powerful 00:00:06.400 --> 00:00:08.460 stuff. Definitely. But maybe you've hit some 00:00:08.460 --> 00:00:11.480 snags, you know, workflows breaking down, APIs 00:00:11.480 --> 00:00:14.199 being kind of tricky, things just getting messy. 00:00:14.419 --> 00:00:16.280 Yeah, happens to everyone starting out. Well, 00:00:16.300 --> 00:00:17.980 you shared a great source with us, and today 00:00:17.980 --> 00:00:20.660 we're going to dive deep into unlocking some 00:00:20.660 --> 00:00:24.250 like... Serious NAN mastery. That's right. Our 00:00:24.250 --> 00:00:27.089 source today is this article, N8N on Automation 00:00:27.089 --> 00:00:30.870 Workflow Mastery, 12 More Secrets, PT2, by Max 00:00:30.870 --> 00:00:34.049 Ann. It's from June 5th, 2025. Right. And it 00:00:34.049 --> 00:00:36.210 builds on part one, which was more foundational 00:00:36.210 --> 00:00:38.350 tricks, I think. Yeah. Part one covered things 00:00:38.350 --> 00:00:40.890 like shortcuts, basic data handling. But this 00:00:40.890 --> 00:00:43.630 one, this gets into the stuff that really makes 00:00:43.630 --> 00:00:47.560 your automation. Yeah. You know, reliable, scalable. 00:00:47.759 --> 00:00:50.000 Yeah. It's like you said, moving from just building 00:00:50.000 --> 00:00:52.439 cool workflows to building proper systems. So 00:00:52.439 --> 00:00:54.579 the mission for this deep dive, unpack these 00:00:54.579 --> 00:00:57.840 next 12 secrets, tricks, hashtag 29 through 40. 00:00:57.939 --> 00:01:01.000 Exactly. And they focus on some key areas, handling 00:01:01.000 --> 00:01:04.400 external API securely, making sure workflows 00:01:04.400 --> 00:01:06.519 don't just die when something glitches. Error 00:01:06.519 --> 00:01:08.400 handling. Yeah, that's a big one. And building 00:01:08.400 --> 00:01:13.620 things in a more organized, powerful way. Using 00:01:13.620 --> 00:01:15.760 patterns. Okay, so these aren't just minor tips 00:01:15.760 --> 00:01:18.659 then? Not at all. These are the techniques that, 00:01:18.680 --> 00:01:20.459 you know, when you apply them consistently, they 00:01:20.459 --> 00:01:22.219 really elevate your automation game. We're going 00:01:22.219 --> 00:01:23.879 to walk through the main ideas from the article. 00:01:24.120 --> 00:01:27.079 All right, let's unpack this. Starting with connecting 00:01:27.079 --> 00:01:31.159 NANN to the outside world, HTTP requests. That's 00:01:31.159 --> 00:01:33.379 pretty fundamental, right? It really is. The 00:01:33.379 --> 00:01:36.359 HTTP request node is basically your gateway to, 00:01:36.500 --> 00:01:39.870 well, almost any API out there. But the article 00:01:39.870 --> 00:01:42.689 says doing it effectively and securely is key. 00:01:42.890 --> 00:01:44.950 Absolutely critical. Which brings the street 00:01:44.950 --> 00:01:47.329 to trick. Hashtag 29. Credential management. 00:01:47.790 --> 00:01:50.150 Okay. And the source calls something terribly 00:01:50.150 --> 00:01:53.530 dangerous. Uh -oh. Sounds serious. Yeah. And 00:01:53.530 --> 00:01:55.150 it really is dangerous. It's talking about hard 00:01:55.150 --> 00:01:57.790 -coding sensitive stuff. You know, API keys, 00:01:58.129 --> 00:02:00.230 access tokens, passwords. Putting them directly 00:02:00.230 --> 00:02:02.269 into the node, like in the settings field. Exactly. 00:02:02.290 --> 00:02:04.409 Typing your actual secret key right into the 00:02:04.409 --> 00:02:06.890 header value box or something. Oh, right. I can 00:02:06.890 --> 00:02:09.680 see why that's bad. If you, like, share that 00:02:09.680 --> 00:02:12.379 workflow file. Or even if someone just gets temporary 00:02:12.379 --> 00:02:14.979 access to your NNN screen or instance. Boom. 00:02:15.240 --> 00:02:18.020 Secrets exposed. Yikes. Massive security hole. 00:02:18.180 --> 00:02:21.580 Huge. Risk of misuse. Financial trouble. Reputation 00:02:21.580 --> 00:02:25.740 damage. Yeah. You just don't do it. It's not 00:02:25.740 --> 00:02:27.719 professional. So what's the right way? What does 00:02:27.719 --> 00:02:29.840 the article recommend? Use NNN's built -in credential 00:02:29.840 --> 00:02:31.599 system. It's specifically designed for this. 00:02:31.620 --> 00:02:33.740 And it's encrypted. Okay. How does that work? 00:02:33.860 --> 00:02:35.740 You go to the credentials section in any of the 00:02:35.740 --> 00:02:38.240 end, hit add credential, pick the type you need, 00:02:38.300 --> 00:02:39.919 often it's generic credential, and then maybe 00:02:39.919 --> 00:02:43.020 header auth for typical API keys. Right. Then 00:02:43.020 --> 00:02:44.939 you give it a really clear name, something you'll 00:02:44.939 --> 00:02:48.300 recognize like OpenAI API key project alpha or 00:02:48.300 --> 00:02:50.120 whatever makes sense. Okay. Then you put in the 00:02:50.120 --> 00:02:52.620 actual header name the API expects, like authorization 00:02:52.620 --> 00:02:55.580 or maybe XAPI key, and then you put the full 00:02:55.580 --> 00:02:58.310 secret value in there. like bear or scale your 00:02:58.310 --> 00:03:00.430 actual key. Gotcha. So the secret lives inside 00:03:00.430 --> 00:03:03.770 that named credential, safely encrypted. Precisely. 00:03:03.930 --> 00:03:07.189 And then back in your HTTP request node, instead 00:03:07.189 --> 00:03:09.189 of typing the secret, you just select the name 00:03:09.189 --> 00:03:10.810 of the credential you created from a dropdown 00:03:10.810 --> 00:03:13.870 list. Ah, so the workflow itself only knows the 00:03:13.870 --> 00:03:16.729 name, not the secret value. Exactly. The benefits 00:03:16.729 --> 00:03:19.240 are huge. Unbreakable security, basically, because 00:03:19.240 --> 00:03:22.020 the value isn't in the workflow JSON. It's safe 00:03:22.020 --> 00:03:23.900 to share workflows because the recipient needs 00:03:23.900 --> 00:03:26.419 to connect their own value to that named credential. 00:03:26.639 --> 00:03:29.659 And easier to manage, I guess, if a key changes. 00:03:30.000 --> 00:03:32.520 Way easier. Update it once in the credentials 00:03:32.520 --> 00:03:35.139 section, and every workflow using that credential 00:03:35.139 --> 00:03:37.259 is automatically updated. It's non -negotiable, 00:03:37.300 --> 00:03:39.699 really. Foundational security practice. Okay, 00:03:39.759 --> 00:03:41.860 makes total sense. Secure credentials first. 00:03:42.080 --> 00:03:45.659 Got it. Trick hashtag 30. This one sounds intriguing. 00:03:46.219 --> 00:03:48.879 The two -minute API integration accelerator. 00:03:49.259 --> 00:03:51.840 What's that about? Oh, this is such a time saver. 00:03:51.919 --> 00:03:53.960 You know how API documentation can sometimes 00:03:53.960 --> 00:03:57.719 be, well, a bit dense? Dense is putting it mildly 00:03:57.719 --> 00:03:59.620 sometimes. Yeah. Trying to figure out the right 00:03:59.620 --> 00:04:03.219 URL, headers, body format. It can take ages just 00:04:03.219 --> 00:04:05.199 for the first simple call. Right. Hours sometimes 00:04:05.199 --> 00:04:07.080 just wrestling with it. The solution here is 00:04:07.080 --> 00:04:09.699 the CURL import trick. CURL, like the command 00:04:09.699 --> 00:04:12.319 line thing. Exactly. Most API docs will give 00:04:12.319 --> 00:04:15.080 you example requests using CRL, or you can maybe 00:04:15.080 --> 00:04:17.399 ask an AI to generate one for you. You find the 00:04:17.399 --> 00:04:19.819 CRL command for the specific API call you want 00:04:19.819 --> 00:04:22.139 to make. So you copy that whole long string, 00:04:22.339 --> 00:04:26.439 like curlhttps .api .example .com at your TC 00:04:26.439 --> 00:04:30.199 gate? Yep. Copy the entire command. Then in N8AN, 00:04:30.259 --> 00:04:32.579 you go to the HTTP request node, and there's 00:04:32.579 --> 00:04:35.040 a button usually labeled import CRL, something 00:04:35.040 --> 00:04:36.899 similar. You click that and paste the command 00:04:36.899 --> 00:04:40.079 in. Oh, happens. It's kind of like magic. N8n 00:04:40.079 --> 00:04:42.740 parses that whole CURL command and automatically 00:04:42.740 --> 00:04:45.220 configures the node for you. It sets the URL, 00:04:45.379 --> 00:04:48.060 the HTTP method, get ET, post ET, whatever. It 00:04:48.060 --> 00:04:50.379 adds the headers, puts the data in the body field. 00:04:50.600 --> 00:04:52.980 Whoa. That saves a ton of clicking and typing. 00:04:53.100 --> 00:04:55.040 It really does. It gets the basic structure right 00:04:55.040 --> 00:04:57.560 instantly. Yeah. And this is important. There's 00:04:57.560 --> 00:04:59.579 a crucial next step the article highlights. Let 00:04:59.579 --> 00:05:02.300 me guess. Credentials. Does it import the hard 00:05:02.300 --> 00:05:05.139 -coded key from the CURL example? Good catch. 00:05:05.379 --> 00:05:08.920 Yes, it often will. If the CURL example had authorization, 00:05:09.379 --> 00:05:12.139 bear your key in it, that might get pulled in 00:05:12.139 --> 00:05:13.620 directly. So you've got to fix that immediately. 00:05:14.120 --> 00:05:16.399 Immediately. Yeah. As soon as you import, you 00:05:16.399 --> 00:05:19.439 review the headers and body, remove any sensitive 00:05:19.439 --> 00:05:22.319 stuff that got pulled in, and replace it by selecting 00:05:22.319 --> 00:05:25.100 your secure N8N credential you just set up using 00:05:25.100 --> 00:05:29.040 trick hashtag 29. Ah, okay. So it accelerates 00:05:29.040 --> 00:05:31.620 the setup, then you apply the security. Still 00:05:31.620 --> 00:05:34.319 sounds way faster. Oh, absolutely. For many APIs, 00:05:34.519 --> 00:05:37.060 you can genuinely go from finding a CURL example 00:05:37.060 --> 00:05:40.420 to making a successful authenticated call in 00:05:40.420 --> 00:05:42.300 under two minutes. It's a massive productivity 00:05:42.300 --> 00:05:45.079 booster. An automation superpower, the article 00:05:45.079 --> 00:05:48.939 calls it. Cool. Okay, trick hashtag 31. dynamic 00:05:48.939 --> 00:05:51.959 HTTP requests with expressions. That sounds like 00:05:51.959 --> 00:05:54.540 making those API calls more flexible, less static. 00:05:54.759 --> 00:05:57.279 Exactly. The initial setup is one thing, but 00:05:57.279 --> 00:05:59.480 in real workflow, your API calls usually need 00:05:59.480 --> 00:06:01.959 to change based on data coming from earlier steps. 00:06:02.160 --> 00:06:04.120 Right. You're not always fetching the same user 00:06:04.120 --> 00:06:06.319 or posting the same static message. Right, the 00:06:06.319 --> 00:06:08.439 data needs to be dynamic. So this trick is all 00:06:08.439 --> 00:06:10.680 about using N8n's expression editor, you know, 00:06:10.699 --> 00:06:12.560 when you type the equal sign in a parameter field. 00:06:12.740 --> 00:06:15.240 Yeah, to use JavaScript and access incoming data. 00:06:15.540 --> 00:06:18.189 Precisely. You can use expressions in the URL 00:06:18.189 --> 00:06:20.269 field, for instance, like the source example, 00:06:20.509 --> 00:06:25.970 https .api .example .com users, plus jstun .userid 00:06:25.970 --> 00:06:29.149 to build the URL based on an incoming user ID. 00:06:29.329 --> 00:06:31.569 Okay, that makes sense. Or you can set headers 00:06:31.569 --> 00:06:33.750 dynamically, maybe add a customer ID from your 00:06:33.750 --> 00:06:37.069 data. Header name x, customer ID value jstun 00:06:37.069 --> 00:06:39.819 .customer .id. And the request body, too. Absolutely. 00:06:39.939 --> 00:06:42.439 You can build entire JSON request bodies where 00:06:42.439 --> 00:06:44.959 the values come from expressions. You can pull 00:06:44.959 --> 00:06:47.459 in data, do calculations, use ifalce logic. Yeah. 00:06:47.540 --> 00:06:49.420 Whatever you need to construct the right payload 00:06:49.420 --> 00:06:52.740 based on the current data item. So one HTTP request 00:06:52.740 --> 00:06:55.079 node can handle lots of variations. Like if it's 00:06:55.079 --> 00:06:57.279 inside a loop processing different items. Exactly. 00:06:57.279 --> 00:06:59.259 Makes the node incredibly versatile and powerful. 00:06:59.459 --> 00:07:01.180 This is really the heart of making automated 00:07:01.180 --> 00:07:03.819 API interactions truly useful adapting to the 00:07:03.819 --> 00:07:06.300 situation. Makes sense. Okay. Last one in this 00:07:06.300 --> 00:07:08.769 section. Hashtag 32. Built -in rate limiting. 00:07:08.930 --> 00:07:11.410 Why is this important? My guess is you don't 00:07:11.410 --> 00:07:13.610 want to annoy the APIs you're talking to. That's 00:07:13.610 --> 00:07:16.170 pretty much it. If your workflow is looping through, 00:07:16.250 --> 00:07:19.170 say, a thousand contacts to update them via an 00:07:19.170 --> 00:07:21.829 API, and you just fire off those requests as 00:07:21.829 --> 00:07:24.209 fast as possible, you're going to slam their 00:07:24.209 --> 00:07:26.149 server. And they probably don't like that. They 00:07:26.149 --> 00:07:28.689 definitely don't. Most APIs have rate limits, 00:07:28.870 --> 00:07:31.310 you know, only X requests allowed per minute 00:07:31.310 --> 00:07:34.209 or per hour. If you exceed that, you'll start 00:07:34.209 --> 00:07:36.769 getting errors, often a 429 too many requests 00:07:36.769 --> 00:07:39.139 error. or they might even temporarily block your 00:07:39.139 --> 00:07:43.209 key. Okay, so n8n helps you be a polite API citizen. 00:07:43.490 --> 00:07:46.230 Yeah, that's a good way to put it. Many nodes, 00:07:46.430 --> 00:07:48.910 definitely the HTTP request node, have built 00:07:48.910 --> 00:07:51.050 -in options for this. Look in the node settings 00:07:51.050 --> 00:07:53.910 or options panner for things like batching, batch 00:07:53.910 --> 00:07:56.730 interval, or pause between requests. And you 00:07:56.730 --> 00:07:59.189 can configure it there? Yep. You can set a batch 00:07:59.189 --> 00:08:02.110 size, like process 100 items at a time, and then 00:08:02.110 --> 00:08:05.129 set an interval between batches, say 60 ,000 00:08:05.129 --> 00:08:06.769 milliseconds, which is 60 seconds. So it would 00:08:06.769 --> 00:08:08.709 run 100 requests, pause for a minute, run the 00:08:08.709 --> 00:08:12.180 next 100. pause like that. Exactly. AAN automatically 00:08:12.180 --> 00:08:14.920 handles that throttling for you. It prevents 00:08:14.920 --> 00:08:16.759 you from hitting those rate limits, which means 00:08:16.759 --> 00:08:20.560 fewer errors, more reliable workflows, and you 00:08:20.560 --> 00:08:23.480 don't risk getting your access revoked. Super 00:08:23.480 --> 00:08:25.480 important, especially when dealing with loops 00:08:25.480 --> 00:08:27.360 or large amounts of data. And you should probably 00:08:27.360 --> 00:08:29.439 check the API's documentation for what their 00:08:29.439 --> 00:08:31.420 limits actually are, right? Oh, absolutely. Always 00:08:31.420 --> 00:08:33.779 check the docs to configure the batching appropriately. 00:08:34.139 --> 00:08:37.090 Cool. That's super useful. Okay, so we've covered 00:08:37.090 --> 00:08:39.629 making the calls securely, quickly, dynamically, 00:08:39.830 --> 00:08:43.210 and politely. But things are still going to go 00:08:43.210 --> 00:08:46.230 wrong sometimes, right? Systems glitch, APIs 00:08:46.230 --> 00:08:50.090 are down, data is weird. Inevitably, something 00:08:50.090 --> 00:08:52.830 will always go wrong eventually. And the article 00:08:52.830 --> 00:08:55.830 is clear. Ignoring error handling is just, well, 00:08:55.909 --> 00:08:57.899 it's a recipe for disaster. building brittle 00:08:57.899 --> 00:09:00.460 automation. So professional design means thinking 00:09:00.460 --> 00:09:03.399 about errors up front. Absolutely. You need intelligent 00:09:03.399 --> 00:09:05.580 error handling for reliability and also just 00:09:05.580 --> 00:09:07.240 to make it easier to figure out what went wrong 00:09:07.240 --> 00:09:09.080 when it goes wrong. It saves so much debugging 00:09:09.080 --> 00:09:12.620 pain. Trick hashtag 33. The error trigger safety 00:09:12.620 --> 00:09:15.460 net. This sounds like a global backup plan. That's 00:09:15.460 --> 00:09:17.159 a perfect way to think about it. It's like a 00:09:17.159 --> 00:09:20.059 big catcher's mitt for any error that slips through 00:09:20.059 --> 00:09:22.500 the cracks anywhere in your Anit10 instance. 00:09:22.820 --> 00:09:25.460 How does that work? Is it a special node? It 00:09:25.460 --> 00:09:27.820 is. You create a completely separate, dedicated 00:09:27.820 --> 00:09:30.840 workflow. Yeah. Just for handling errors. And 00:09:30.840 --> 00:09:32.659 this workflow starts with a special node called 00:09:32.659 --> 00:09:35.220 the error trigger. Okay. And when does that trigger 00:09:35.220 --> 00:09:37.740 fire? It fires automatically whenever any other 00:09:37.740 --> 00:09:42.000 active workflow in your NNN instance fails. And 00:09:42.000 --> 00:09:44.299 that failed workflow doesn't have its own successful 00:09:44.299 --> 00:09:47.240 error handling path defined right where the failure 00:09:47.240 --> 00:09:49.000 happened. Oh, interesting. So it catches the 00:09:49.000 --> 00:09:50.940 stuff that isn't handled locally. Exactly. It's 00:09:50.940 --> 00:09:53.399 the fallback. And in this dedicated error handler 00:09:53.399 --> 00:09:55.659 workflow, the first thing you should do is send 00:09:55.659 --> 00:09:59.360 a really comprehensive notification. Slack. Email, 00:09:59.600 --> 00:10:02.220 push bullet, whatever gets your attention. Comprehensive 00:10:02.220 --> 00:10:04.700 like, telling you what broke. Yes, and much more. 00:10:04.840 --> 00:10:07.059 The error trigger node provides a ton of useful 00:10:07.059 --> 00:10:09.980 context. The article lists the critical details 00:10:09.980 --> 00:10:12.320 you should include in your alert. The name and 00:10:12.320 --> 00:10:15.000 ID of the workflow that failed. The name and 00:10:15.000 --> 00:10:16.980 type of the node that failed. Okay, that's helpful 00:10:16.980 --> 00:10:19.700 already. The actual error message and maybe the 00:10:19.700 --> 00:10:22.279 stack trace, the specific execution ID so you 00:10:22.279 --> 00:10:25.559 can find it in N8n, the timestamp, a direct link 00:10:25.559 --> 00:10:28.399 to the execution log in N8n. Oh, a link right 00:10:28.399 --> 00:10:31.200 to the failed run. That's huge. It's incredibly 00:10:31.200 --> 00:10:33.440 useful for debugging. Yeah. And it even often 00:10:33.440 --> 00:10:35.740 includes a sample of the input data that was 00:10:35.740 --> 00:10:37.940 going into the node when it failed. Wow. Okay. 00:10:37.960 --> 00:10:40.059 Getting an alert with all of that in one go would 00:10:40.059 --> 00:10:42.840 cut down debugging time like massively. Seriously. 00:10:42.980 --> 00:10:45.440 The beauty is, as the source has set it up once, 00:10:45.600 --> 00:10:48.370 benefit everywhere. You get this baseline critical 00:10:48.370 --> 00:10:51.070 error awareness for all unhandled failures across 00:10:51.070 --> 00:10:54.250 your entire instance. Simplifies debugging, helps 00:10:54.250 --> 00:10:56.830 you monitor overall system health. It's like 00:10:56.830 --> 00:10:58.950 a global error trap. Okay, that's the global 00:10:58.950 --> 00:11:01.850 safety net. But what if you know a specific step 00:11:01.850 --> 00:11:04.289 might fail sometimes and you want to handle it 00:11:04.289 --> 00:11:07.259 right there? Trick hashtag 34. Branch -level 00:11:07.259 --> 00:11:09.419 error handling with continue on fail. Right. 00:11:09.500 --> 00:11:12.340 This is for more granular, localized handling. 00:11:12.600 --> 00:11:15.679 Think about a specific HTTP request node talking 00:11:15.679 --> 00:11:18.019 to an occasionally flaky third -party service, 00:11:18.220 --> 00:11:20.639 or maybe a database write that could fail if 00:11:20.639 --> 00:11:22.460 the record already exists, or something predictable 00:11:22.460 --> 00:11:24.879 like that. And you don't want the entire workflow 00:11:24.879 --> 00:11:28.120 to just stop dead if that one step fails for 00:11:28.120 --> 00:11:30.460 one item in a loop, maybe. Exactly. You might 00:11:30.460 --> 00:11:32.779 want to log the error for that item and let the 00:11:32.779 --> 00:11:36.100 rest continue. So on that specific node, the 00:11:36.100 --> 00:11:39.080 HTTP request, the database node, whatever you 00:11:39.080 --> 00:11:41.820 go into its settings tab. Okay. And you find 00:11:41.820 --> 00:11:44.320 and enable the option called continue on fail 00:11:44.320 --> 00:11:46.899 or sometimes continue on error. And what does 00:11:46.899 --> 00:11:49.850 that do? Add another output. Precisely. It adds 00:11:49.850 --> 00:11:51.990 a second output connector to the node, often 00:11:51.990 --> 00:11:54.210 shown in red or labeled as the error output. 00:11:54.750 --> 00:11:57.409 Now, if the node runs successfully, the data 00:11:57.409 --> 00:11:59.769 flows out the normal main output connector as 00:11:59.769 --> 00:12:02.149 usual. But if it fails? If it fails, the execution 00:12:02.149 --> 00:12:05.210 doesn't stop. Instead, information about the 00:12:05.210 --> 00:12:07.629 error plus the original input data that caused 00:12:07.629 --> 00:12:09.929 the failure gets sent out through that new error 00:12:09.929 --> 00:12:12.330 output connector. Ah, so you can connect nodes 00:12:12.330 --> 00:12:14.629 after that error output to define a specific 00:12:14.629 --> 00:12:17.250 error path just for failures of that node? Exactly. 00:12:17.309 --> 00:12:19.659 And in that error path, You decide what to do. 00:12:19.899 --> 00:12:23.100 Maybe send a very specific alert. Fail to update 00:12:23.100 --> 00:12:26.500 Recodex. Maybe log the air details to a dedicated 00:12:26.500 --> 00:12:29.370 air table or Google Sheet. Maybe try a backup 00:12:29.370 --> 00:12:31.669 plan, like calling a different API endpoint. 00:12:31.830 --> 00:12:34.250 Or maybe just gracefully stop processing that 00:12:34.250 --> 00:12:36.370 item, but let the main workflow continue with 00:12:36.370 --> 00:12:39.009 the next item. Yes, you have control. It allows 00:12:39.009 --> 00:12:41.309 you to build tailored responses to predictable 00:12:41.309 --> 00:12:44.289 errors right at the source, making the workflow 00:12:44.289 --> 00:12:46.409 much more resilient for those kinds of partial 00:12:46.409 --> 00:12:48.629 failures. That makes a lot of sense for handling 00:12:48.629 --> 00:12:51.730 individual failures within a larger batch. What 00:12:51.730 --> 00:12:55.610 about temporary glitches? Like a brief network 00:12:55.610 --> 00:12:58.649 hiccup or the API being momentarily overloaded. 00:12:58.649 --> 00:13:00.909 Is there something for that trick? Hashtag 35, 00:13:01.070 --> 00:13:04.509 using built -in retry mechanisms. Yes. And this 00:13:04.509 --> 00:13:07.190 is important. Don't reinvent the wheel by building 00:13:07.190 --> 00:13:09.370 complex retry loops yourself if you don't have 00:13:09.370 --> 00:13:12.809 to. Many nodes, especially the HTTP request node 00:13:12.809 --> 00:13:15.090 and lots of the dedicated app nodes like Google 00:13:15.090 --> 00:13:18.009 Sheets, Slack, etc., have retry logic built right 00:13:18.009 --> 00:13:20.169 in. Oh, really? Where do you find that? Again, 00:13:20.289 --> 00:13:23.830 usually in the nodes settings tab. Look for options 00:13:23.830 --> 00:13:27.789 like retry on fail, retry count, or retry attempts, 00:13:28.090 --> 00:13:31.370 and retry interval. So you can just tell it, 00:13:31.409 --> 00:13:34.309 like, if this fails, try again three times, waiting 00:13:34.309 --> 00:13:36.850 five seconds between tries. Exactly that. You 00:13:36.850 --> 00:13:38.850 can configure how many times it should retry 00:13:38.850 --> 00:13:41.379 and how long it should wait. Some nodes even 00:13:41.379 --> 00:13:44.460 support exponential backoff, where it waits longer 00:13:44.460 --> 00:13:46.820 between each subsequent retry, which is often 00:13:46.820 --> 00:13:48.940 a good practice. Oh, that's smart. So it automatically 00:13:48.940 --> 00:13:51.279 gives it a few more chances before actually giving 00:13:51.279 --> 00:13:53.740 up and considering it a failure. Right. This 00:13:53.740 --> 00:13:56.200 handles those common transient failures, the 00:13:56.200 --> 00:13:59.080 network blips, the momentary overloads completely 00:13:59.080 --> 00:14:02.000 transparently. It happens in the background without 00:14:02.000 --> 00:14:05.259 you needing complex IF nodes and loops just for 00:14:05.259 --> 00:14:07.549 retries. That sounds like it would significantly 00:14:07.549 --> 00:14:10.009 improve reliability against those short -lived 00:14:10.009 --> 00:14:13.070 external issues. It really does. But remember, 00:14:13.230 --> 00:14:16.029 the key here is transient issues. If the error 00:14:16.029 --> 00:14:19.309 is persistent, like a wrong API key, retrying 00:14:19.309 --> 00:14:21.669 won't help. That's when you still need your local 00:14:21.669 --> 00:14:24.149 error path, hashtag 34, or the global safety 00:14:24.149 --> 00:14:27.429 net, hashtag 33, to catch the final unrecoverable 00:14:27.429 --> 00:14:29.990 failure after the retries are exhausted. Gotcha. 00:14:30.269 --> 00:14:32.669 Retries for temporary stuff, error paths for 00:14:32.669 --> 00:14:35.220 stuff that stays broken. Okay. Trick hashtag 00:14:35.220 --> 00:14:38.059 36 is called centralized error management via 00:14:38.059 --> 00:14:40.519 workflow settings. And the source calls it the 00:14:40.519 --> 00:14:43.700 ultimate safety combo. Sounds like this ties 00:14:43.700 --> 00:14:46.460 everything together. It absolutely does. This 00:14:46.460 --> 00:14:48.519 is where you combine the global and local strategies 00:14:48.519 --> 00:14:52.039 for a really effective, robust, and importantly, 00:14:52.220 --> 00:14:55.299 maintainable error handling system across your 00:14:55.299 --> 00:14:58.519 whole NEN setup. How does it work? First, you 00:14:58.519 --> 00:15:00.100 make sure you have that global error handler 00:15:00.100 --> 00:15:02.019 workflow we talked about in trick hashtag 33, 00:15:02.320 --> 00:15:04.279 the one starting with the error trigger, and 00:15:04.279 --> 00:15:06.360 make sure it's active. Okay, the global catcher's 00:15:06.360 --> 00:15:09.080 mitt is ready. Then, for any individual workflow 00:15:09.080 --> 00:15:10.980 where you want this enhanced error handling, 00:15:11.159 --> 00:15:13.320 which is probably most of them, you go to its 00:15:13.320 --> 00:15:15.919 main workflow settings. Not a specific node settings, 00:15:16.159 --> 00:15:18.159 but the overall settings for the entire workflow, 00:15:18.379 --> 00:15:20.559 usually accessible from the top of the canvas. 00:15:20.799 --> 00:15:22.899 Right, the workflow level settings. And in there, 00:15:23.000 --> 00:15:25.240 you'll find an option typically called error 00:15:25.240 --> 00:15:27.730 workflow. You click that. And you select your 00:15:27.730 --> 00:15:29.710 dedicated error handler workflow from the list. 00:15:29.909 --> 00:15:32.649 Ah, so you're explicitly linking this workflow 00:15:32.649 --> 00:15:35.789 to your central error handler. Exactly. Now, 00:15:35.850 --> 00:15:37.870 here's the clever routing the article describes. 00:15:38.190 --> 00:15:43.110 If a node inside this workflow fails, NAN first 00:15:43.110 --> 00:15:45.730 checks if that node has a local continue on fail 00:15:45.730 --> 00:15:48.590 error path defined. Trick, hashtag 34. Okay. 00:15:48.809 --> 00:15:51.409 If it does have a local path and that local path 00:15:51.409 --> 00:15:54.289 runs successfully, then great. The local handling 00:15:54.289 --> 00:15:56.570 takes care of it. The error doesn't go any further. 00:15:56.730 --> 00:15:58.570 Right. Local handling takes precedence if it 00:15:58.570 --> 00:16:00.990 works. But if the node fails and it does not 00:16:00.990 --> 00:16:03.370 have a local error path defined, or if it does 00:16:03.370 --> 00:16:05.789 have a local path, but that path itself fails 00:16:05.789 --> 00:16:08.090 for some reason. Then what? Then the error is 00:16:08.090 --> 00:16:10.590 automatically caught and routed to the centrally 00:16:10.590 --> 00:16:13.490 assigned error handler workflow that you selected 00:16:13.490 --> 00:16:15.809 in the workflow setting. Oh, wow. So the central 00:16:15.809 --> 00:16:18.490 handler becomes the ultimate backup. It catches 00:16:18.490 --> 00:16:21.009 anything not handled locally plus failures within 00:16:21.009 --> 00:16:23.940 the local handling. Precisely. It creates this 00:16:23.940 --> 00:16:26.440 powerful multilayered safety net. You handle 00:16:26.440 --> 00:16:28.220 the predictable stuff locally where it makes 00:16:28.220 --> 00:16:31.080 sense, and your central handler catches absolutely 00:16:31.080 --> 00:16:33.960 everything else, the unexpected failures, the 00:16:33.960 --> 00:16:36.659 ones you didn't plan for, even failures in your 00:16:36.659 --> 00:16:39.019 error handling code itself. That sounds incredibly 00:16:39.019 --> 00:16:41.940 robust and consistent across all the workflows 00:16:41.940 --> 00:16:44.279 you set it up for. Exactly. It makes debugging 00:16:44.279 --> 00:16:47.500 way easier because, you know. all unhandled errors 00:16:47.500 --> 00:16:50.159 end up in one place with detailed context. It 00:16:50.159 --> 00:16:52.899 dramatically improves reliability and just makes 00:16:52.899 --> 00:16:55.480 your whole automation setup feel much more professional 00:16:55.480 --> 00:16:58.259 and manageable. Awesome. Okay, so we've got solid 00:16:58.259 --> 00:17:01.379 HTTP calls and now really comprehensive error 00:17:01.379 --> 00:17:04.140 handling. Let's move on to building things. Smarter, 00:17:04.240 --> 00:17:07.400 I guess. Part seven in the source is advanced 00:17:07.400 --> 00:17:09.460 workflow patterns. Yeah, this section shifts 00:17:09.460 --> 00:17:11.599 focus from individual node tricks to how you 00:17:11.599 --> 00:17:14.039 actually structure your workflows. Implementing 00:17:14.039 --> 00:17:15.740 architectural patterns for solutions that are 00:17:15.740 --> 00:17:18.359 organized, maintainable, scalable. You know, 00:17:18.359 --> 00:17:19.980 thinking like an automation architect. Okay, 00:17:20.019 --> 00:17:23.319 first pattern. Trick hashtag 37. Multi -trigger 00:17:23.319 --> 00:17:26.180 standardization. Why do triggers need standardizing? 00:17:26.180 --> 00:17:28.480 Don't they just start the workflow? They do start 00:17:28.480 --> 00:17:32.059 it. But the problem arises when the same core 00:17:32.059 --> 00:17:34.660 piece of automation logic needs to be triggered 00:17:34.660 --> 00:17:37.160 in multiple ways. Maybe sometimes you run it 00:17:37.160 --> 00:17:40.640 manually. Sometimes it runs on a schedule. Sometimes 00:17:40.640 --> 00:17:42.720 it's triggered by a webhook call from another 00:17:42.720 --> 00:17:46.259 system. Right. Okay. And? And the issue is each 00:17:46.259 --> 00:17:49.500 of those trigger types often provides the initial 00:17:49.500 --> 00:17:52.380 data. to the workflow in a slightly different 00:17:52.380 --> 00:17:56.140 format the webhook might send data as customer 00:17:56.140 --> 00:17:59.400 mail ordered while the manual trigger might just 00:17:59.400 --> 00:18:02.160 have a simple input field named email and schedule 00:18:02.160 --> 00:18:04.579 trigger might have no input data at all initially 00:18:04.579 --> 00:18:07.400 oh yeah i've hit that then the node later that 00:18:07.400 --> 00:18:09.200 expects customer mail breaks when the workflow 00:18:09.200 --> 00:18:10.960 runs from the manual trigger because it only 00:18:10.960 --> 00:18:13.819 got email super annoying exactly it's a classic 00:18:13.819 --> 00:18:16.380 source of it works when i run it manually but 00:18:16.380 --> 00:18:20.109 fails on the schedule problems The solution proposed 00:18:20.109 --> 00:18:22.829 here is simple, but really effective. What is 00:18:22.829 --> 00:18:24.769 it? You have your multiple trigger nodes, manual, 00:18:24.930 --> 00:18:27.490 schedule, webhook, etc. But immediately after 00:18:27.490 --> 00:18:30.009 each trigger, you connect it to its own dedicated 00:18:30.009 --> 00:18:32.589 set node, or maybe a small sequence of nodes 00:18:32.589 --> 00:18:35.349 if needed. Okay, a set node right after each 00:18:35.349 --> 00:18:38.170 trigger. What does it do? Its only job is to 00:18:38.170 --> 00:18:40.650 take the incoming data from that specific trigger, 00:18:40.789 --> 00:18:43.190 whatever format it's in, and transform it into 00:18:43.190 --> 00:18:46.089 a single standardized format. that the rest of 00:18:46.089 --> 00:18:48.450 your workflow expects. It maps the fields to 00:18:48.450 --> 00:18:51.430 consistent names. So the set node after the webhook 00:18:51.430 --> 00:18:54.509 takes customer mail and outputs it as, say, standard 00:18:54.509 --> 00:18:57.170 email, and the set node after the manual trigger 00:18:57.170 --> 00:18:59.849 takes email and also outputs it as standard email. 00:19:00.190 --> 00:19:02.329 Precisely. All these standardizing set nodes 00:19:02.329 --> 00:19:05.009 then feed into the main common logic path of 00:19:05.009 --> 00:19:07.640 your workflow. which means that main logic always 00:19:07.640 --> 00:19:10.640 receives its input data in the exact same structure 00:19:10.640 --> 00:19:13.079 with the same field names, regardless of how 00:19:13.079 --> 00:19:14.759 the workflow was started. Ah, that's clever. 00:19:14.960 --> 00:19:17.480 It decouples the trigger specifics from the core 00:19:17.480 --> 00:19:19.900 logic. I bet that cuts down way down on those 00:19:19.900 --> 00:19:22.720 kinds of input -related bugs. Dramatically. Your 00:19:22.720 --> 00:19:24.900 core logic becomes much easier to test and far 00:19:24.900 --> 00:19:27.119 more reliable because it only ever has to deal 00:19:27.119 --> 00:19:29.500 with one predictable input format. Nice. Okay. 00:19:29.579 --> 00:19:32.660 Trick hashtag 38. Modular workflow design with 00:19:32.660 --> 00:19:35.380 execute workflow. This sounds like breaking things 00:19:35.380 --> 00:19:37.000 up, making workflows out of other workflows. 00:19:37.259 --> 00:19:40.079 Essentially, yes. And it's a massive win for 00:19:40.079 --> 00:19:43.220 maintainability and reusability. Think about 00:19:43.220 --> 00:19:45.960 common tasks you perform in many different automations. 00:19:46.400 --> 00:19:49.000 Maybe it's a sequence of nodes that takes a customer 00:19:49.000 --> 00:19:51.930 email. looks them up in your CRM, fetches their 00:19:51.930 --> 00:19:54.789 order history from Shopify, and then calculates 00:19:54.789 --> 00:19:56.670 their lifetime value. Yeah, you might need that 00:19:56.670 --> 00:19:58.650 customer enrichment logic in lots of different 00:19:58.650 --> 00:20:01.650 places. Exactly. Now imagine copying and pasting 00:20:01.650 --> 00:20:04.170 that whole group of five or six nodes into a 00:20:04.170 --> 00:20:06.250 dozen different workflows. What happens when 00:20:06.250 --> 00:20:08.289 you need to tweak that logic? Maybe add another 00:20:08.289 --> 00:20:10.789 data source or change how LPV is calculated? 00:20:11.130 --> 00:20:14.059 Ugh. You have to go find and update it in all 00:20:14.059 --> 00:20:16.640 12 places and hope you don't miss one or make 00:20:16.640 --> 00:20:19.299 a mistake. Nightmare. Total nightmare. The solution 00:20:19.299 --> 00:20:22.160 is modularity. You create reusable sub workflows 00:20:22.160 --> 00:20:25.119 or modules for these common tasks. And the key 00:20:25.119 --> 00:20:27.819 tool N8 provides for this is the execute workflow 00:20:27.819 --> 00:20:30.740 node. Okay, so how does that work? I build a 00:20:30.740 --> 00:20:33.519 separate workflow just for that enriched customer 00:20:33.519 --> 00:20:36.460 data logic. Exactly. You create this child workflow. 00:20:37.140 --> 00:20:39.319 It typically starts with a simple trigger, like 00:20:39.319 --> 00:20:42.019 a webhook or manual trigger, just so it can receive 00:20:42.019 --> 00:20:45.000 input data, like the customer email. It performs 00:20:45.000 --> 00:20:48.059 its specific self -contained task, enriching 00:20:48.059 --> 00:20:50.099 the data, and then makes sure to output the results. 00:20:50.400 --> 00:20:52.700 Okay, so it's a standalone workflow that does 00:20:52.700 --> 00:20:56.079 one job well. Right. Then in your main parent 00:20:56.079 --> 00:20:58.019 workflows where you need that enrichment logic, 00:20:58.240 --> 00:21:00.480 instead of copying all those nodes, you just 00:21:00.480 --> 00:21:03.089 add a single execute workflow node. And in that 00:21:03.089 --> 00:21:05.269 node, you point it to the child workflow. Yep. 00:21:05.289 --> 00:21:07.450 You configure the execute workflow node, select 00:21:07.450 --> 00:21:09.569 the enrich customer data child workflow from 00:21:09.569 --> 00:21:11.769 a list, and you map the data the child needs, 00:21:11.890 --> 00:21:14.589 the email address, as input. What happens then? 00:21:14.710 --> 00:21:17.670 Does the parent wait? Yes. The parent workflow 00:21:17.670 --> 00:21:20.250 typically pauses at the execute workflow node. 00:21:20.630 --> 00:21:22.690 The child workflow runs with the data it was 00:21:22.690 --> 00:21:25.470 given. When the child finishes, the execute workflow 00:21:25.470 --> 00:21:28.069 node in the parent receives the output data from 00:21:28.069 --> 00:21:30.769 the child, and the parent workflow resumes. using 00:21:30.769 --> 00:21:34.269 that enriched data. Wow. That's huge for reusability. 00:21:34.509 --> 00:21:36.269 It's like creating your own custom high -level 00:21:36.269 --> 00:21:38.869 nodes out of other workflows. It's exactly like 00:21:38.869 --> 00:21:41.650 that. It embodies the DRY principle. Don't repeat 00:21:41.650 --> 00:21:44.970 yourself. The benefits are massive. Update the 00:21:44.970 --> 00:21:47.970 logic in one child workflow, and all parent workflows 00:21:47.970 --> 00:21:50.890 using it are instantly updated. Your main workflows 00:21:50.890 --> 00:21:52.750 become much cleaner and easier to understand 00:21:52.750 --> 00:21:55.490 because complex steps are abstracted away. And 00:21:55.490 --> 00:21:58.700 maintenance. Drastically simpler. It's fundamental 00:21:58.700 --> 00:22:01.539 for building complex, maintainable systems in 00:22:01.539 --> 00:22:03.940 NANN. Okay, definitely need to try that one. 00:22:04.019 --> 00:22:07.119 Trick, hashtag 39. The versatile switch node. 00:22:07.339 --> 00:22:09.940 We mentioned IF nodes earlier for simple true 00:22:09.940 --> 00:22:12.640 -false branches, but what if you have logic that 00:22:12.640 --> 00:22:15.160 needs to go down one of like five or six different 00:22:15.160 --> 00:22:17.839 paths based on some value, like different customer 00:22:17.839 --> 00:22:20.519 tiers or different error codes? Trying to handle 00:22:20.519 --> 00:22:22.920 that with nested IF nodes gets incredibly messy 00:22:22.920 --> 00:22:25.299 really fast. It becomes hard to read, hard to 00:22:25.299 --> 00:22:27.779 follow, hard to maintain. The switch node is 00:22:27.779 --> 00:22:30.039 designed precisely for this scenario. The source 00:22:30.039 --> 00:22:32.440 calls it a multi -way traffic director, which 00:22:32.440 --> 00:22:34.440 is a pretty good analogy. Okay, so how does it 00:22:34.440 --> 00:22:37.319 work differently from an IF? An IF node evaluates 00:22:37.319 --> 00:22:39.819 a condition to true or false and gives you two 00:22:39.819 --> 00:22:43.019 paths. A switch node evaluates one single input 00:22:43.019 --> 00:22:45.940 value. Maybe it's... jtnson .orderStatus or json 00:22:45.940 --> 00:22:49.059 .customerTier, against multiple defined conditions 00:22:49.059 --> 00:22:51.240 or cases that you set up. So you feed it the 00:22:51.240 --> 00:22:53.900 status, and it checks if it's pending, shipped, 00:22:54.140 --> 00:22:57.279 canceled, etc. Exactly. You add a switch node, 00:22:57.460 --> 00:22:59.980 and in its settings, you first specify the value 00:22:59.980 --> 00:23:02.720 to switch on using an expression. Then you add 00:23:02.720 --> 00:23:06.019 routing rules or cases. For each rule, you define 00:23:06.019 --> 00:23:09.529 a condition, like string .equalsNumber. greater 00:23:09.529 --> 00:23:12.990 than regex .matches, and the specific value to 00:23:12.990 --> 00:23:15.890 compare against, like pending, shipped, 100, 00:23:16.230 --> 00:23:18.710 or regex pattern. And each rule gets its own 00:23:18.710 --> 00:23:20.549 output connector coming out of the switch node. 00:23:20.650 --> 00:23:22.589 Yes. Output 0 for the first rule that matches, 00:23:22.670 --> 00:23:24.490 output 1 for the second rule, output 2, and so 00:23:24.490 --> 00:23:27.289 on. So the data flows down only the path corresponding 00:23:27.289 --> 00:23:29.769 to the first rule it matches. What if it doesn't 00:23:29.769 --> 00:23:32.450 match any of the rules? Ah, crucial point. There's 00:23:32.450 --> 00:23:35.349 also a default output connector. Any data that 00:23:35.349 --> 00:23:37.609 doesn't match any of the specific rules you defined 00:23:37.609 --> 00:23:39.849 will automatically flow out through the default 00:23:39.849 --> 00:23:42.309 output. This is super important for handling 00:23:42.309 --> 00:23:44.730 unexpected values or having a fallback path. 00:23:45.150 --> 00:23:47.170 The examples in the source make sense now, routing 00:23:47.170 --> 00:23:50.369 customers based on gold, silver, bronze tier, 00:23:50.609 --> 00:23:53.650 processing different order statuses, maybe even 00:23:53.650 --> 00:23:56.049 handling specific API error codes differently, 00:23:56.250 --> 00:23:58.930 like route 401 errors to a re -authentication 00:23:58.930 --> 00:24:03.509 path, 429 errors to a delay and retry path, 500 00:24:03.509 --> 00:24:06.559 errors to an alert path. Exactly those kinds 00:24:06.559 --> 00:24:08.779 of scenarios. Yeah. It makes that sort of complex 00:24:08.779 --> 00:24:11.220 multi -branch decision logic so much cleaner, 00:24:11.279 --> 00:24:13.740 more organized, and vastly easier to understand 00:24:13.740 --> 00:24:16.359 and modify later compared to a tangled mess of 00:24:16.359 --> 00:24:18.759 nested IFs. It's a cornerstone node for any kind 00:24:18.759 --> 00:24:20.960 of sophisticated rule -based processing. Got 00:24:20.960 --> 00:24:23.150 it. All right. Last pattern. Trick hashtag 40. 00:24:23.509 --> 00:24:25.329 Precision timing with advanced cron scheduling. 00:24:25.589 --> 00:24:27.630 The regular schedule trigger in ANN is pretty 00:24:27.630 --> 00:24:29.509 straightforward, right? Like run every hour or 00:24:29.509 --> 00:24:32.329 run every day at 9 a .m. Yeah. For simple, common 00:24:32.329 --> 00:24:34.170 schedules, the basic options in the schedule 00:24:34.170 --> 00:24:37.029 trigger node are usually fine. Run every X minutes, 00:24:37.230 --> 00:24:39.970 hours, days, specific day of the week, specific 00:24:39.970 --> 00:24:42.109 time. But what if you need something much more 00:24:42.109 --> 00:24:45.049 specific or complex, like run only on the 1st 00:24:45.049 --> 00:24:48.130 and 15th of the month at 2 .30 a .m. or run every 00:24:48.130 --> 00:24:50.809 10 minutes, but only during weekends? Exactly. 00:24:51.109 --> 00:24:53.529 For those kinds of highly specific, granular 00:24:53.529 --> 00:24:55.970 timing requirements, the basic options aren't 00:24:55.970 --> 00:24:58.049 enough. That's where you need the power of full 00:24:58.049 --> 00:25:00.589 cron syntax. And the schedule trigger node does 00:25:00.589 --> 00:25:03.069 support this. It has a cron mode. Cron. That's 00:25:03.069 --> 00:25:05.190 that cryptic line of stars and numbers, right? 00:25:05.289 --> 00:25:07.809 Like pre. That's the one. It's a time -based 00:25:07.809 --> 00:25:10.130 job scaffolding system that comes from the Unix 00:25:10.130 --> 00:25:13.250 Linux world. It uses a specific syntax with five 00:25:13.250 --> 00:25:16.130 fields or sometimes six. What do the fields mean? 00:25:16.450 --> 00:25:18.750 Typically, the five fields represent minute. 00:25:19.079 --> 00:25:23.460 059, hour 023, day of the month 131, month 112, 00:25:23.680 --> 00:25:26.599 and day of the week 0 to 7, where both 0 and 00:25:26.599 --> 00:25:29.079 7 can represent Sunday, or sometimes it's 17 00:25:29.079 --> 00:25:32.400 for monsoon. Using numbers, commas for lists, 00:25:32.660 --> 00:25:35.059 hyphens for ranges, and the asterisk as a wildcard, 00:25:35.180 --> 00:25:37.539 meaning every, you can define incredibly specific 00:25:37.539 --> 00:25:40.769 schedules. Okay. Sounds powerful, but also kind 00:25:40.769 --> 00:25:42.930 of intimidating to write yourself. It can be 00:25:42.930 --> 00:25:45.130 at first. The source gives a couple of clearer 00:25:45.130 --> 00:25:48.150 examples. Running a report every Wednesday at 00:25:48.150 --> 00:25:52.069 2 .10 p .m. would be 0143. Zero minutes past 00:25:52.069 --> 00:25:54.470 the 14th hour, any day of the month, any month, 00:25:54.490 --> 00:25:57.549 on the third day of the week, Wednesday. Or a 00:25:57.549 --> 00:25:59.670 monitoring check that runs every 15 minutes, 00:25:59.829 --> 00:26:02.369 but only during business hours, 9 a .m. to 5 00:26:02.369 --> 00:26:04.890 p .m., which is 1700, Monday through Friday. 00:26:05.109 --> 00:26:08.730 That would be 15, 9, 17, 1 to 5. 15 for every 00:26:08.730 --> 00:26:12.309 15th minute, 9 -17 for hours 9 -17 any day month, 00:26:12.450 --> 00:26:15.410 and 1 -5 from Monday to Friday. Wow. Okay. That's 00:26:15.410 --> 00:26:17.390 super specific. It offers extremely granular 00:26:17.390 --> 00:26:19.839 control. But yeah, figuring out the syntax can 00:26:19.839 --> 00:26:22.279 be tricky. The source wisely suggests using online 00:26:22.279 --> 00:26:24.740 resources. There are websites like crontab .guru 00:26:24.740 --> 00:26:27.259 or various online cron generators, where you 00:26:27.259 --> 00:26:29.099 can often use a more user -friendly interface 00:26:29.099 --> 00:26:31.240 to build a schedule you want, and it will spit 00:26:31.240 --> 00:26:32.819 out the correct cron string for you to paste 00:26:32.819 --> 00:26:35.319 into an ADEM. Ah, that's a good tip, user generator. 00:26:35.740 --> 00:26:38.079 So this cron mode is really for those critical 00:26:38.079 --> 00:26:40.740 business processes, complex reporting schedules, 00:26:41.019 --> 00:26:43.299 or time -sensitive tasks where the basic options 00:26:43.299 --> 00:26:45.599 just don't cut it. Exactly. It's definitely a 00:26:45.599 --> 00:26:48.440 power user feature, but... essential when you 00:26:48.440 --> 00:26:50.299 need that level of precision timing. Okay, wow. 00:26:50.460 --> 00:26:52.559 So those are the 12 advanced tricks from part 00:26:52.559 --> 00:26:55.319 two of the article covering HTTP requests, error 00:26:55.319 --> 00:26:57.980 handling, and these architectural patterns. Quite 00:26:57.980 --> 00:27:00.240 a lot of powerful stuff there. The article also 00:27:00.240 --> 00:27:02.240 mentioned a 30 -day mastery plan at the end. 00:27:02.400 --> 00:27:04.599 It does, yeah. It pulls together all 40 tricks 00:27:04.599 --> 00:27:07.319 from part one and part two into a suggested structured 00:27:07.319 --> 00:27:09.799 learning plan. It basically breaks down the practice 00:27:09.799 --> 00:27:12.160 week by week. Like focus on certain skills each 00:27:12.160 --> 00:27:14.660 week. Exactly. Week one might be reinforcing 00:27:14.660 --> 00:27:17.680 the foundations and basic data handling. Week 00:27:17.680 --> 00:27:20.079 two could be deeper data manipulation and initial 00:27:20.079 --> 00:27:23.019 API work with secure credentials. Week three 00:27:23.019 --> 00:27:25.579 might focus on advanced data structures, looping, 00:27:25.599 --> 00:27:28.079 and really implementing robust error handling. 00:27:28.339 --> 00:27:30.519 And week four could be about practicing these 00:27:30.519 --> 00:27:33.220 architectural patterns, modularity, switching, 00:27:33.559 --> 00:27:36.500 standardization, and getting workflows production 00:27:36.500 --> 00:27:39.019 ready. So the goal isn't just to know about these 00:27:39.019 --> 00:27:41.740 tricks. Right. The goal is consistent, focused 00:27:41.740 --> 00:27:44.539 practice to not just understand them intellectually, 00:27:44.720 --> 00:27:47.380 but to internalize them, to build the muscle 00:27:47.380 --> 00:27:49.460 memory. So you start applying them naturally 00:27:49.460 --> 00:27:51.519 as you build. That makes sense. And the article 00:27:51.519 --> 00:27:53.660 really drives home the impact this has. Right. 00:27:53.799 --> 00:27:56.440 It talks about the transformation, the before 00:27:56.440 --> 00:27:59.019 and after. It really does. And the before picture 00:27:59.019 --> 00:28:01.440 it paints is probably familiar to many folks 00:28:01.440 --> 00:28:04.380 who've wrestled with automation. Hours of painstaking, 00:28:04.539 --> 00:28:08.099 error prone work. Brittle workflows that break 00:28:08.099 --> 00:28:11.539 if you look at them wrong. Long, stressful debugging 00:28:11.539 --> 00:28:15.579 sessions. Messy, undocumented canvases. Maybe 00:28:15.579 --> 00:28:18.799 wasting API credits on failed calls. Security 00:28:18.799 --> 00:28:22.099 risks lurking. Uh, yeah. Maybe sounds a tiny 00:28:22.099 --> 00:28:23.960 bit familiar in spots. Okay, maybe more than 00:28:23.960 --> 00:28:26.079 tiny. Huh, we've all been there. But the after 00:28:26.079 --> 00:28:28.160 picture, once you start consistently applying 00:28:28.160 --> 00:28:30.700 these techniques. It's a different world. Building 00:28:30.700 --> 00:28:32.920 that same workflow might take minutes or hours, 00:28:32.940 --> 00:28:35.240 not days, and you build it with high confidence. 00:28:35.400 --> 00:28:37.119 Okay, I like the sound of that. Your workflows 00:28:37.119 --> 00:28:40.140 become resilient. They handle failures gracefully, 00:28:40.299 --> 00:28:42.839 either alerting you properly or routing errors 00:28:42.839 --> 00:28:45.220 intelligently. Your workflow canvas becomes clear, 00:28:45.339 --> 00:28:47.160 maybe even self -documenting with good naming 00:28:47.160 --> 00:28:49.740 and notes. Development time and costs go down. 00:28:50.200 --> 00:28:52.519 Credentials are secure. Your whole system becomes 00:28:52.519 --> 00:28:55.220 modular, maintainable, scalable. Collaboration 00:28:55.220 --> 00:28:57.299 gets easier. That really is a profound shift. 00:28:57.460 --> 00:28:59.839 It's moving from automation that, you know, sometimes 00:28:59.839 --> 00:29:03.279 works and is a pain to fix to architecting systems 00:29:03.279 --> 00:29:06.680 that reliably deliver business value. Absolutely. 00:29:06.859 --> 00:29:09.880 And it directly addresses that desire we see 00:29:09.880 --> 00:29:12.079 in learners wanting knowledge that's quick to 00:29:12.079 --> 00:29:15.529 grasp, but also thorough. and provides a clear 00:29:15.529 --> 00:29:18.089 path away from feeling overwhelmed toward building 00:29:18.089 --> 00:29:20.829 dependable professional solutions. Okay, so let's 00:29:20.829 --> 00:29:22.450 bring it home for you, the listener. You've just 00:29:22.450 --> 00:29:25.410 heard this overview of 12 power -packed NAN techniques. 00:29:26.210 --> 00:29:28.170 What's the takeaway? What should you do now? 00:29:28.529 --> 00:29:31.210 Well, the first thing the article stresses, don't 00:29:31.210 --> 00:29:33.130 try to implement all 40 tricks overnight. That's 00:29:33.130 --> 00:29:34.730 just going to be overwhelming. Right, don't boil 00:29:34.730 --> 00:29:37.509 the ocean. Exactly. Adopt an iterative approach. 00:29:37.849 --> 00:29:40.109 The source suggests a sort of immediate action 00:29:40.109 --> 00:29:43.460 plan. Okay, what's involved? A few options. You 00:29:43.460 --> 00:29:45.619 could revisit the areas in that 30 -day plan 00:29:45.619 --> 00:29:48.140 outline that you know are maybe weaker spots 00:29:48.140 --> 00:29:52.059 for you currently, or maybe easier to start. 00:29:52.740 --> 00:29:55.619 Pick just one of the advanced patterns we discussed 00:29:55.619 --> 00:29:59.319 today. Like execute workflow or switch or multi 00:29:59.319 --> 00:30:01.500 -trigger standardization or cron scheduling. 00:30:01.819 --> 00:30:04.559 Yeah, pick just one of those and make a conscious 00:30:04.559 --> 00:30:07.539 effort to implement it in a real workflow sometime 00:30:07.539 --> 00:30:09.779 this week. Maybe refactor an existing workflow 00:30:09.779 --> 00:30:12.440 to use it or build a small new one specifically 00:30:12.440 --> 00:30:15.079 to practice it. Okay, that feels way more achievable. 00:30:15.220 --> 00:30:18.640 Just one thing to try. Or another great starting 00:30:18.640 --> 00:30:21.200 point. Take one of your older, maybe slightly 00:30:21.200 --> 00:30:23.619 messy workflows. Go back and look at it with 00:30:23.619 --> 00:30:25.240 fresh eyes, applying some of these principles. 00:30:25.460 --> 00:30:27.880 Can you improve the node naming? Add some markdown 00:30:27.880 --> 00:30:30.460 sticky notes to explain complex sections. Move 00:30:30.460 --> 00:30:32.460 any hard -coded credentials over to the secure 00:30:32.460 --> 00:30:35.839 credential manager. Add basic continue -on -fail 00:30:35.839 --> 00:30:38.380 error handling to a node that sometimes causes 00:30:38.380 --> 00:30:40.480 trouble. Oh yeah, refactoring something you already 00:30:40.480 --> 00:30:42.599 built is a great way to learn. You see the direct 00:30:42.599 --> 00:30:46.259 improvement. Absolutely. You learn a ton by applying 00:30:46.259 --> 00:30:48.740 these ideas to your own real -world problems. 00:30:48.839 --> 00:30:51.599 And seriously, don't underestimate just cleaning 00:30:51.599 --> 00:30:54.099 up naming and adding nodes. Future you will be 00:30:54.099 --> 00:30:56.140 incredibly grateful. It really sounds like the 00:30:56.140 --> 00:30:58.420 core message is that the difference between someone 00:30:58.420 --> 00:31:01.400 just using NAN and someone who's really mastering 00:31:01.400 --> 00:31:04.440 it, a wizard as the article puts it, isn't just 00:31:04.440 --> 00:31:07.200 about how long they've used it. Not just time, 00:31:07.220 --> 00:31:10.000 no. It's the deliberate, consistent application 00:31:10.000 --> 00:31:13.859 of these specific, powerful techniques and best 00:31:13.859 --> 00:31:16.099 practices. That's what truly makes the difference. 00:31:16.259 --> 00:31:18.480 These are the force multipliers for your automation 00:31:18.480 --> 00:31:21.109 efforts. That's a fantastic way to put it. These 00:31:21.109 --> 00:31:24.190 techniques transform NAN from just a useful tool 00:31:24.190 --> 00:31:26.630 into, yeah, like you said earlier, a superpower. 00:31:27.009 --> 00:31:29.410 The knowledge is out there now. The playbook, 00:31:29.410 --> 00:31:31.670 at least this part of it, is outlined. So here's 00:31:31.670 --> 00:31:34.059 that final thought for you to chew on. Think 00:31:34.059 --> 00:31:36.000 about a current workflow challenge you're wrestling 00:31:36.000 --> 00:31:38.400 with right now. Is there just one insight or 00:31:38.400 --> 00:31:41.599 technique from this deep dive? Maybe secure credentials, 00:31:41.940 --> 00:31:45.079 maybe the CURL import, maybe an error handling 00:31:45.079 --> 00:31:47.339 strategy, maybe the switch node that could provide 00:31:47.339 --> 00:31:49.500 the breakthrough you've been looking for? Because 00:31:49.500 --> 00:31:51.880 the path to mastery isn't just about listening 00:31:51.880 --> 00:31:55.190 or reading. It's about... That deliberate practice, 00:31:55.390 --> 00:31:57.809 applying these proven techniques to your own 00:31:57.809 --> 00:32:00.369 automations. Go forth and build amazing things 00:32:00.369 --> 00:32:04.250 with more power, more precision, and maybe a 00:32:04.250 --> 00:32:05.930 little bit of that wizardry. Sounds like a plan. 00:32:06.130 --> 00:32:07.529 See you next time for another deep dive.