WEBVTT 00:00:00.000 --> 00:00:02.700 Have you ever felt that, that little friction, 00:00:02.720 --> 00:00:04.820 that feeling you're hitting a kind of ceiling 00:00:04.820 --> 00:00:07.440 with your automation tools? Like they're amazing, 00:00:07.440 --> 00:00:10.359 right? But sometimes they just, they can't quite 00:00:10.359 --> 00:00:12.839 do that one specific thing you need, that custom 00:00:12.839 --> 00:00:16.120 bit, you know, beyond the standard blocks. It 00:00:16.120 --> 00:00:18.320 feels like there's something more powerful hidden 00:00:18.320 --> 00:00:21.620 away, maybe a secret weapon. That secret weapon. 00:00:21.739 --> 00:00:23.699 Yeah. That's exactly what we're digging into 00:00:23.699 --> 00:00:26.339 today. Welcome everyone to the deep dive. I'm 00:00:26.339 --> 00:00:27.980 actually really excited about this one. We get 00:00:27.980 --> 00:00:30.469 to unpack something super powerful. Today, we're 00:00:30.469 --> 00:00:33.109 taking that deep dive into the NAN code node, 00:00:33.530 --> 00:00:35.890 which, let's be honest, for a lot of folks, it 00:00:35.890 --> 00:00:38.549 kind of looks like this. Complex, maybe even 00:00:38.549 --> 00:00:41.369 intimidating code thing inside a platform that's 00:00:41.369 --> 00:00:43.710 otherwise pretty friendly. Oh, totally understandable. 00:00:43.810 --> 00:00:46.270 It does look a bit scary from the outside. But 00:00:46.270 --> 00:00:49.250 our mission today is simple. Pull back that curtain. 00:00:49.609 --> 00:00:52.570 Make it clear. We want to show you how this thing 00:00:52.570 --> 00:00:55.649 that seems like a big programming hurdle is actually 00:00:56.079 --> 00:00:58.619 Well, it's a clear path to doing some seriously 00:00:58.619 --> 00:01:01.619 next level automation. We're going to cover handling 00:01:01.619 --> 00:01:04.579 tricky data, calling other services, processing 00:01:04.579 --> 00:01:07.560 big batches of stuff, and even creating your 00:01:07.560 --> 00:01:10.200 own files right inside NAN. It's way more doable 00:01:10.200 --> 00:01:12.439 than you might think. OK, let's unpack that. 00:01:12.599 --> 00:01:14.480 Because it is a common thought, I've definitely 00:01:14.480 --> 00:01:17.459 felt it myself, that the code node is strictly 00:01:17.459 --> 00:01:19.239 for the super hardcore programmers, the ones 00:01:19.239 --> 00:01:21.599 who just breathe JavaScript, has that vibe, doesn't 00:01:21.599 --> 00:01:24.159 it? It absolutely does. Makes you hesitate, maybe 00:01:24.159 --> 00:01:26.170 click something else instead. But here's the 00:01:26.170 --> 00:01:28.409 kicker, the really interesting part. You can 00:01:28.409 --> 00:01:31.909 get the basics down surprisingly fast, like really 00:01:31.909 --> 00:01:34.890 fast, a focused afternoon maybe, just to get 00:01:34.890 --> 00:01:38.769 the core ideas. And once you do, oh man, it completely 00:01:38.769 --> 00:01:42.709 unlocks what NEN can do. Think about other platforms 00:01:42.709 --> 00:01:46.370 like Make or Zapier, great tools. But they just 00:01:46.370 --> 00:01:48.310 don't offer this level of custom logic, this 00:01:48.310 --> 00:01:51.930 deep dive into manipulating data. The code node... 00:01:51.530 --> 00:01:54.569 pushes N8n way beyond those limits. You can do 00:01:54.569 --> 00:01:57.049 complex data transformations, call external APIs 00:01:57.049 --> 00:02:00.010 in real time, process huge amounts of info, generate 00:02:00.010 --> 00:02:02.930 custom files, reports, data exports, whatever. 00:02:03.310 --> 00:02:05.310 It turns the N8n from just an orchestrator into 00:02:05.310 --> 00:02:07.489 a real data processing engine. That sounds like 00:02:07.489 --> 00:02:09.610 it could really... Yeah, revolutionize how people 00:02:09.610 --> 00:02:12.169 use it. So fundamentally, then, how does it actually 00:02:12.169 --> 00:02:14.210 process the information? Is it looking at things 00:02:14.210 --> 00:02:16.669 one by one or the whole lot together? That's 00:02:16.669 --> 00:02:18.509 the beauty. It's flexible. It can handle items 00:02:18.509 --> 00:02:20.430 individually, like processing each order separately, 00:02:20.430 --> 00:02:23.129 or it can look at the entire batch, the whole 00:02:23.129 --> 00:02:25.849 collection as one single unit. That flexibility. 00:02:25.889 --> 00:02:28.229 Yeah, that sounds key for different kinds of 00:02:28.229 --> 00:02:30.650 problems. Now, to really get a handle on this, 00:02:30.729 --> 00:02:33.370 I imagine setting up a little sandbox, a practice 00:02:33.370 --> 00:02:36.110 area is probably the way to go. Oh, absolutely. 00:02:36.229 --> 00:02:39.080 Best way to learn is just jump in. FIRO blank 00:02:39.080 --> 00:02:41.680 workflow in any in. So for our example, let's 00:02:41.680 --> 00:02:44.259 imagine you've got some sample order data. Picture 00:02:44.259 --> 00:02:46.860 it like a JavaScript array. Basically a list, 00:02:46.979 --> 00:02:49.120 right? A list of product objects. What's an object? 00:02:49.199 --> 00:02:51.400 Think of it like a digital box for each product, 00:02:51.439 --> 00:02:54.439 laptop, mouse, whatever. And inside that box 00:02:54.439 --> 00:02:57.400 are details like price, quantity, maybe custom 00:02:57.400 --> 00:03:00.560 email. Now a key thing is understanding how to 00:03:00.560 --> 00:03:02.979 handle that list. Do you process each product 00:03:02.979 --> 00:03:06.099 one at a time? We're all together. And ENN actually 00:03:06.099 --> 00:03:08.139 has a node called split out that does exactly 00:03:08.139 --> 00:03:09.939 that, breaks the list into individual items. 00:03:10.580 --> 00:03:12.180 But, and this is cool, the code node can also 00:03:12.180 --> 00:03:14.120 do that splitting internally if you want, or 00:03:14.120 --> 00:03:16.379 control. Exactly. So the code node basically 00:03:16.379 --> 00:03:18.419 has these two main ways it operates. The first 00:03:18.419 --> 00:03:21.020 is run once for each item. That's the default. 00:03:21.120 --> 00:03:23.300 It processes each item, each product in our list, 00:03:23.639 --> 00:03:25.419 totally on its own. The second mode is run once 00:03:25.419 --> 00:03:27.659 for all items. This one treats everything together 00:03:27.659 --> 00:03:30.080 as one big list, one array. When you first add 00:03:30.080 --> 00:03:31.879 a code node, it actually gives you a little snippet 00:03:31.879 --> 00:03:34.340 of code already. Super simple, just adds a field 00:03:34.340 --> 00:03:35.939 called my new field to show you how it works, 00:03:36.159 --> 00:03:38.060 how it outputs data. Okay, okay, so let's make 00:03:38.060 --> 00:03:41.560 it concrete, a practical example. How about calculating 00:03:41.560 --> 00:03:45.139 a line total, price times quantity for each product, 00:03:45.400 --> 00:03:47.819 and maybe extracting just the domain name from 00:03:47.819 --> 00:03:50.419 an email address, like gettingexample .com from 00:03:50.419 --> 00:03:53.520 someone at example .com. Perfect examples, everyday 00:03:53.520 --> 00:03:56.830 stuff where the code note is brilliant. So first, 00:03:56.849 --> 00:03:59.469 you need the data for the current item. You use 00:03:59.469 --> 00:04:02.270 input .item .json. That basically tells the code 00:04:02.270 --> 00:04:04.310 node, get me the data for this specific item 00:04:04.310 --> 00:04:07.330 right now. Calculating line total, easy peasy, 00:04:07.569 --> 00:04:11.710 just price quantity, basic math. Now, the email 00:04:11.710 --> 00:04:14.669 domain. That's where you use string manipulation. 00:04:15.229 --> 00:04:17.709 JavaScript has tools for this, methods like substring, 00:04:17.910 --> 00:04:20.209 index off. Think of index off as asking, where's 00:04:20.209 --> 00:04:22.870 the at symbol? It gives you the position. Then 00:04:22.870 --> 00:04:24.629 substring says, okay, give me everything after 00:04:24.629 --> 00:04:27.339 that position. Together, they let you snip out 00:04:27.339 --> 00:04:30.079 just the domain. But here's something really 00:04:30.079 --> 00:04:31.959 important, especially when you're starting out. 00:04:32.500 --> 00:04:35.399 The spread operator. Those three dots dot order 00:04:35.399 --> 00:04:37.819 item. This little trick says, keep all the original 00:04:37.819 --> 00:04:40.060 data from this item and then add my new line 00:04:40.060 --> 00:04:43.339 total and customer domain fields. And if you 00:04:43.339 --> 00:04:45.600 forget it, poof, all your original data disappears 00:04:45.600 --> 00:04:47.420 and you only get the new fields. Common mistake. 00:04:47.540 --> 00:04:49.660 I gotta admit, I still wrestle with remembering 00:04:49.660 --> 00:04:51.680 all those specific string methods myself sometimes 00:04:51.680 --> 00:04:53.379 when I'm actually writing the code. It's a small 00:04:53.379 --> 00:04:55.550 thing, but... Yeah, it can trip you up. Oh, you're 00:04:55.550 --> 00:04:57.269 definitely not alone there. It really just comes 00:04:57.269 --> 00:05:00.430 with doing it more. But the key is knowing that 00:05:00.430 --> 00:05:03.550 these tools exist and roughly what they do. So 00:05:03.550 --> 00:05:05.850 you know what to look up or, you know, ask an 00:05:05.850 --> 00:05:09.370 AI helper about. So, OK, we've done things one 00:05:09.370 --> 00:05:11.170 by one, but what about looking at the whole picture, 00:05:11.290 --> 00:05:13.769 the entire data set? How does it handle that? 00:05:14.379 --> 00:05:16.920 That collection all at once right it shifts into 00:05:16.920 --> 00:05:19.459 that bash mode viewing all the items together 00:05:19.459 --> 00:05:22.480 as one Big array like going from single letters 00:05:22.480 --> 00:05:25.120 to reading the whole page and this this is where 00:05:25.120 --> 00:05:27.199 it gets seriously interesting This is where you 00:05:27.199 --> 00:05:30.000 unlock stuff. That's frankly much harder or impossible 00:05:30.000 --> 00:05:32.519 and other tools I'm talking about the code nodes 00:05:32.519 --> 00:05:35.980 ability to directly call external API's this 00:05:35.980 --> 00:05:39.259 is huge it turns in 8n in this amazing hub that 00:05:39.259 --> 00:05:41.800 can pull in data from Well, practically anywhere 00:05:41.800 --> 00:05:43.899 on the web that offers an API. That really does 00:05:43.899 --> 00:05:46.120 set it apart, doesn't it? Grabbing external data 00:05:46.120 --> 00:05:48.480 on the fly, that's a massive potential. It's 00:05:48.480 --> 00:05:50.600 absolutely massive. Magi, you have your product 00:05:50.600 --> 00:05:52.680 data, right? And you want to enrich it by getting, 00:05:52.680 --> 00:05:55.939 say, barcode info from a free API like world 00:05:55.939 --> 00:05:58.500 .openfoodfacts .org. You just use your product 00:05:58.500 --> 00:06:02.910 ID. code for this, you'll see keywords like async 00:06:02.910 --> 00:06:04.829 and await. These are super important for things 00:06:04.829 --> 00:06:07.430 that take time, like waiting for an API response. 00:06:07.629 --> 00:06:09.410 Think of async as telling your workflow, hey, 00:06:09.550 --> 00:06:11.269 this next step might take a while. Don't just 00:06:11.269 --> 00:06:13.310 freeze up. And await is where you actually say, 00:06:13.410 --> 00:06:16.189 OK. Pause here and wait for this specific thing 00:06:16.189 --> 00:06:18.810 to finish. Like waiting for a download. LANN 00:06:18.810 --> 00:06:21.129 helps a lot here with a built -in helper. This 00:06:21.129 --> 00:06:24.589 .helpers .http request makes calling APIs much 00:06:24.589 --> 00:06:27.269 simpler. No need for extra libraries. You'd also 00:06:27.269 --> 00:06:29.009 want to check the response .status basically. 00:06:29.089 --> 00:06:31.110 Did the call work? Did the server respond okay? 00:06:31.449 --> 00:06:33.750 And crucially, never ever put your secret API 00:06:33.750 --> 00:06:36.250 keys directly in the code. Use NAN's credentials 00:06:36.250 --> 00:06:38.550 feature. Always. It keeps them safe. Think of 00:06:38.550 --> 00:06:40.189 it like a password manager for your workflows. 00:06:40.629 --> 00:06:43.009 Whoa. Okay. Just thinking about that. Imagine 00:06:43.009 --> 00:06:46.490 scaling that. integrating with dozens of different 00:06:46.490 --> 00:06:48.889 services all at once, pulling in real -time data 00:06:48.889 --> 00:06:51.410 for really complex decisions. It's not just moving 00:06:51.410 --> 00:06:53.389 data around anymore, is it? It's like building 00:06:53.389 --> 00:06:56.050 a live intelligence system. Exactly. Imagine 00:06:56.050 --> 00:06:59.649 an e -commerce setup pulling real -time shipping 00:06:59.649 --> 00:07:02.569 rates from five carriers, checking inventory 00:07:02.569 --> 00:07:05.290 levels across three warehouses, maybe factoring 00:07:05.290 --> 00:07:08.449 in current promotions, and then deciding the 00:07:08.449 --> 00:07:11.310 absolute best way to fulfill an order all before 00:07:11.310 --> 00:07:13.829 the user even finishes checkout. That's the kind 00:07:13.829 --> 00:07:16.889 of dynamic smart stuff this unlocks. It's way 00:07:16.889 --> 00:07:19.569 beyond simple triggers and actions. So OK, we've 00:07:19.569 --> 00:07:21.149 looked at individual items, enriched them with 00:07:21.149 --> 00:07:24.389 APIs. But what if you have thousands, hundreds 00:07:24.389 --> 00:07:26.329 of thousands of items? You need the big picture, 00:07:26.569 --> 00:07:28.689 right? Beyond individuals, how do we summarize 00:07:28.689 --> 00:07:30.490 everything? That sounds like the perfect job 00:07:30.490 --> 00:07:32.709 for batch processing, right? Crunching all that 00:07:32.709 --> 00:07:35.500 data together for the aggregate view. Precisely. 00:07:35.680 --> 00:07:37.339 That's where the run once for all items mode 00:07:37.339 --> 00:07:39.639 is king. You just toggle a setting in the node, 00:07:39.920 --> 00:07:41.980 and suddenly instead of input .item for one thing, 00:07:42.199 --> 00:07:44.860 you get items, which is an array, a list, holding 00:07:44.860 --> 00:07:47.819 all your input data. If 100 orders came in, items 00:07:47.819 --> 00:07:50.639 has all 100. So now you can easily calculate 00:07:50.639 --> 00:07:52.560 things like total revenue across all orders, 00:07:52.920 --> 00:07:55.480 or total items sold, or even create a more complex 00:07:55.480 --> 00:07:58.240 category report, having up sales per category. 00:07:58.279 --> 00:08:02.720 A really useful pattern here is often items .json 00:08:02.720 --> 00:08:05.850 .map. you loop through the list and pull out 00:08:05.850 --> 00:08:08.930 just the data you need from each item. The JavaScript 00:08:08.930 --> 00:08:11.389 produce method becomes your best friend. It's 00:08:11.389 --> 00:08:13.290 like the ultimate tool for boiling down a list. 00:08:13.769 --> 00:08:15.930 Want to sum up all the numbers? Count items by 00:08:15.930 --> 00:08:18.490 category dot reduce is perfect. It takes your 00:08:18.490 --> 00:08:20.550 whole list and processes it down to a single 00:08:20.550 --> 00:08:23.250 summary value or object. Just one little detail 00:08:23.250 --> 00:08:25.629 to remember. When you return data in bash mode, 00:08:25.889 --> 00:08:27.509 the final output needs to be an array containing 00:08:27.509 --> 00:08:29.569 just one object that holds your summary results, 00:08:29.870 --> 00:08:31.509 like putting your final report in a single folder. 00:08:31.730 --> 00:08:33.710 OK, so we've processed everything, got our summaries. 00:08:33.830 --> 00:08:35.929 But what about getting that information out, 00:08:36.169 --> 00:08:38.549 like into a format? that we can use elsewhere. 00:08:38.649 --> 00:08:41.870 Can the code node actually create files? Yes, 00:08:41.970 --> 00:08:44.350 it absolutely can. You can generate custom files 00:08:44.350 --> 00:08:46.610 directly from your processed data. Now that is 00:08:46.610 --> 00:08:49.409 seriously impressive. Making files CSVs, JSON, 00:08:49.570 --> 00:08:52.230 maybe even a formatted HTML report right inside 00:08:52.230 --> 00:08:54.169 the workflow. That's not just processing data, 00:08:54.210 --> 00:08:56.610 it's producing results. It's a total game changer, 00:08:56.690 --> 00:08:59.250 yeah. So let's say you took those stats we calculated 00:08:59.250 --> 00:09:02.350 in batch mode and you want an HTML report. How 00:09:02.350 --> 00:09:05.230 do you do it? First, you grab the data from the 00:09:05.230 --> 00:09:07.649 previous node. Let's say that node was named 00:09:07.649 --> 00:09:11.429 calculateStats. You'd use something like calculateStats 00:09:11.429 --> 00:09:14.549 .item .json to pull its output into your current 00:09:14.549 --> 00:09:17.649 code node, symbol reference. Then... You build 00:09:17.649 --> 00:09:20.450 your HTML. The best way is using template literals. 00:09:20.470 --> 00:09:22.889 Those are strings using backticks instead of 00:09:22.889 --> 00:09:25.149 quotes. They make it super easy to embed your 00:09:25.149 --> 00:09:27.730 data right into the HTML text, like mail merge 00:09:27.730 --> 00:09:30.169 almost. Finally, you need to package it up. Use 00:09:30.169 --> 00:09:32.549 buffer .from to turn your text into binary data 00:09:32.549 --> 00:09:35.710 and then this .helpers .prepare binary data. 00:09:36.360 --> 00:09:38.320 Think of these helpers like putting your report 00:09:38.320 --> 00:09:40.460 in a digital envelope, labeling it with a file 00:09:40.460 --> 00:09:43.519 name like report .html, and specifying the MIME 00:09:43.519 --> 00:09:46.080 type like text email. What's a MIME type? It 00:09:46.080 --> 00:09:47.480 just tells the computer what kind of file it 00:09:47.480 --> 00:09:49.419 is, HTML text, a JPEG image, et cetera, so it 00:09:49.419 --> 00:09:51.500 knows how to open it. The key thing for file 00:09:51.500 --> 00:09:53.860 output is the return structure. You need a JSON 00:09:53.860 --> 00:09:56.419 property for metadata and a binary property holding 00:09:56.419 --> 00:09:58.919 the actual file content. OK, that covers the 00:09:58.919 --> 00:10:01.779 core capabilities from single items right through 00:10:01.779 --> 00:10:05.070 to making files. That's a lot. Let's shift gears 00:10:05.070 --> 00:10:07.850 slightly. Advanced techniques, best practices. 00:10:08.269 --> 00:10:10.149 What's maybe the number one thing people miss 00:10:10.149 --> 00:10:12.409 when they start using this more seriously? Error 00:10:12.409 --> 00:10:15.669 handling. Easily. Hands down. Look, APIs fail 00:10:15.669 --> 00:10:18.110 sometimes. Networks glitch. Data might not be 00:10:18.110 --> 00:10:20.429 what you expected. You absolutely need to wrap 00:10:20.429 --> 00:10:23.129 code that might fail, especially those API calls 00:10:23.129 --> 00:10:25.950 in what's called a try that catch block. If you 00:10:25.950 --> 00:10:28.190 don't, one little hiccup can crash your whole 00:10:28.190 --> 00:10:31.000 workflow. With try .catch, if an error happens 00:10:31.000 --> 00:10:33.039 in the try part, the catch part runs instead. 00:10:33.320 --> 00:10:35.580 You can log the error, maybe send a notification, 00:10:35.779 --> 00:10:37.740 return a default value. It keeps things running 00:10:37.740 --> 00:10:40.539 smoothly. It's crucial for reliability. Performance 00:10:40.539 --> 00:10:43.379 tips. Definitely use batch mode. Run once for 00:10:43.379 --> 00:10:46.220 all items. For large data sets, if you can. Fewer 00:10:46.220 --> 00:10:48.620 executions is faster. If you are looping through 00:10:48.620 --> 00:10:51.080 lots of API calls, add a small delay between 00:10:51.080 --> 00:10:53.139 them. Like, wait half a second, seriously. It 00:10:53.139 --> 00:10:54.759 stops you hitting rate limits and getting blocked 00:10:54.759 --> 00:10:57.039 by the API provider. Happens more than you think. 00:10:57.939 --> 00:11:00.779 And, oh, keep your code nodes focused. If one 00:11:00.779 --> 00:11:02.879 starts doing too much, split the logic into two 00:11:02.879 --> 00:11:05.259 or three smaller nodes, way easier to debug and 00:11:05.259 --> 00:11:07.399 manage later, like breaking down a big project. 00:11:07.659 --> 00:11:10.279 And speaking of debugging, how do you actually 00:11:10.279 --> 00:11:12.360 see what's going on inside the code while it's 00:11:12.360 --> 00:11:14.620 running? How do you peek under the hood? Good 00:11:14.620 --> 00:11:17.419 old console .log. It's simple, but it's effective. 00:11:17.980 --> 00:11:21.070 You can put console .log some variable anywhere 00:11:21.070 --> 00:11:23.450 in your code. When the workflow runs, whatever 00:11:23.450 --> 00:11:26.029 you log shows up in the NAN Developer Tools panel 00:11:26.029 --> 00:11:29.049 or the server logs. Perfect for checking variable 00:11:29.049 --> 00:11:31.669 values, seeing if code paths are being hit, just 00:11:31.669 --> 00:11:35.370 understanding the flow. And one last thing, don't 00:11:35.370 --> 00:11:38.070 shy away from using AI assistants like ChatGPT 00:11:38.070 --> 00:11:41.139 or Claude. Seriously, give them good context. 00:11:41.179 --> 00:11:43.539 Here's my code. Here's the input data structure. 00:11:43.580 --> 00:11:45.779 I want to achieve X. And they can often spit 00:11:45.779 --> 00:11:48.039 out really useful code snippets. Generative AI 00:11:48.039 --> 00:11:50.259 just means AI that creates stuff like code. They 00:11:50.259 --> 00:11:52.179 won't replace understanding why it works, but 00:11:52.179 --> 00:11:54.460 man, they can speed things up. That's all really 00:11:54.460 --> 00:11:56.620 solid advice. OK, so boiling it all down. If 00:11:56.620 --> 00:11:58.919 there's one single most important thing for someone 00:11:58.919 --> 00:12:00.519 listening right now, just starting with the code 00:12:00.519 --> 00:12:03.039 node, what should they remember? What's the core 00:12:03.039 --> 00:12:06.299 message? Start simple. Don't try to boil the 00:12:06.299 --> 00:12:08.700 ocean on day one. Build a complexity gradually. 00:12:08.879 --> 00:12:13.240 and just practice, tinker, experiment. So wrapping 00:12:13.240 --> 00:12:16.659 up this deep dive, we've really explored how 00:12:16.659 --> 00:12:19.559 getting comfortable with the N8n code node genuinely 00:12:19.559 --> 00:12:22.139 transforms the platform. It elevates it, doesn't 00:12:22.139 --> 00:12:24.399 it? From a straightforward automation tool to 00:12:24.399 --> 00:12:27.659 something much more like a... a powerful, flexible 00:12:27.659 --> 00:12:30.500 engine for data processing and complex workflow 00:12:30.500 --> 00:12:32.840 orchestration. It's a real step up. Absolutely. 00:12:32.940 --> 00:12:35.299 And we hit the four key pillars, right? Handling 00:12:35.299 --> 00:12:38.159 individual items, bringing in external data via 00:12:38.159 --> 00:12:41.539 APIs, crunching numbers in bash mode, and even 00:12:41.539 --> 00:12:44.600 generating custom output files. It truly is that 00:12:44.600 --> 00:12:47.279 secret weapon for tackling those more advanced 00:12:47.279 --> 00:12:49.419 automation challenges that used to feel out of 00:12:49.419 --> 00:12:51.850 reach. The only way to really internalize this, 00:12:51.850 --> 00:12:53.990 though, is by doing. So we really hope you'll 00:12:53.990 --> 00:12:55.909 open up any now, and maybe right after this, 00:12:56.090 --> 00:12:57.809 start a blank workflow and just play around. 00:12:58.169 --> 00:13:00.009 Try it with some data you have. Don't worry about 00:13:00.009 --> 00:13:01.950 getting it perfect immediately. Just experiment. 00:13:02.370 --> 00:13:04.269 Breaking things is part of learning here. Yeah, 00:13:04.289 --> 00:13:06.690 totally. Remember, the code note isn't just another 00:13:06.690 --> 00:13:08.429 note in the canvas. It's more like a gateway, 00:13:09.029 --> 00:13:11.809 a gateway to, well, pretty much unlimited potential 00:13:11.809 --> 00:13:13.990 in your workflows. Your imagination really does 00:13:13.990 --> 00:13:16.720 become the main constraint. And as you start 00:13:16.720 --> 00:13:18.700 experimenting, maybe think about this. What's 00:13:18.700 --> 00:13:21.779 one repetitive data heavy task you deal with 00:13:21.779 --> 00:13:24.440 regularly? Something tedious, maybe. How could 00:13:24.440 --> 00:13:26.600 applying even a little bit of custom logic with 00:13:26.600 --> 00:13:28.840 the code node to that one task fundamentally 00:13:28.840 --> 00:13:31.620 change how you work or free up significant time? 00:13:31.919 --> 00:13:33.639 What could that unlock for you? Go build something 00:13:33.639 --> 00:13:34.820 awesome. Go to your own music.