5 n8n Tips You NEED to Know

Dr. Violet Howard covers five essential n8n tips: continuing workflows on error, setting up parent-child agent communication, centralizing error notifications, choosing between || and ?? operators, and using From AI to auto-populate fields. A bonus tip explains why explicit node references beat generic shortcuts for maintainability.
Chapters
What's going on guys? In today's video, we'll be diving into these 5 tips that everyone needs to know if you plan on using N8N to automate workflows or build AI agents. Make sure you watch this one all the way through because at the end I'll be going over a bonus tip. Let's not waste any time and get straight into tip number 1. The first thing that we're gonna be talking about is continuing on error. This means setting up your workflow that if a single item doesn't go through, it's not going to break the whole automation. So we've got 3 examples to walk through in this tip. Here's the first example. What we're doing here is we have 3 URLs, McDonald's, Chipotle, and then a fake one. And we're looping through each of those URLs to scrape the website content. And right here in this HTTP request, if you look at the settings and you go to On Error, we're stopping the workflow if anything errors. So when that third URL errors, it's going to stop the whole workflow. And if there was more logic taking place over here, it wouldn't matter, the whole thing would break. So let's hit Test Step. We will see that now, um, in this HTTP request, we have the third run errored, but then the first and the second one actually had content come back. So now you can see why that broke the whole automation. So here's example number 2. Everything's the same except for in the HTTP request, if we go into settings, we're having it continue on error. So let's run this real quick and we'll see what happens. The first 2 are going to go through, and even though the 3rd one errored, the workflow didn't error, the workflow didn't break. So in here we can see that there were 3 items coming back, and if we go to JSON, we can see that the first 2 got scraped and the 3rd one had nothing. But the workflow is going to continue going down this path as if nothing happened. And it's not gonna break the whole thing. And now here's the third example. Let's say that even though it's continuing on error, we wanna see which one's errored. So now we have in the loop over items, we can go to settings and on error, it's going to continue, but it's not just going to continue, it's going to have an extra output called error. So as you can see right here, we have done, loop, and error. And if we go back into the previous example, we only had done and loop. So this is cool because now we will be getting anything that errors out of this loop is going to come down here in Set Field, just as an example, and we'll be able to see what's running and what's not. So if we hit Test Workflow, we'll see that we got this worked, no errors. We have 2 items coming back in the Done branch, which is now, you know, the McDonald's and the Chipotle got scraped. But if we go to the error URLs, we can see this URL errored because it's just an example URL, nothing to scrape, and it's invalid. So that's how you could sort of see what's going on based on the way you choose to continue on error or continue on error with an error output. Tip number 2, we're gonna dive into how you can have agents talk to each other so that your workflows are smarter and more efficient. So 2 workflows we're gonna talk about in this one. We have a parent agent, which would be your standard sort of tools agent that's gonna, um, have access to different N8N workflows you may have already built out. So this one we have a child agent, and then if we switch over to the child agent, this is what it looks like. It's just a simple tool with Wikipedia, and I'll get into what's going on here. But basically we have these different, um, response fields, right? So. In the parent agent, when we go into the workflow, it's going to be looking for a field called response. Once we sort of give it that query, it'll hit this, this agent right here, and then it will be waiting until the child agent responds, and that way it can take action in another tool or maybe respond back to us. So what we did in the child workflow is we have these different areas where it could respond. So in this case, if the, the original query we're looking for if it exists or not, which is the query that the parent agent will be sending over, sometimes it just won't include a query and you don't want that because then the rest of the workflow won't run as it's supposed to do. So in here, we're simulating that the agent, the parent agent sends over a query that doesn't actually exist. If we run this, now this branch is going to send it this way, which is a response field just telling the parent agent, no query exists, please try again. And that way it sees what it did wrong and then it will send over a new query. So that's an initial step you could do. And you could have these, this logic implemented in multiple steps. But then we have the agent will get the answer from Wikipedia. And then we have this model, which is just checking if the, the answer is quality, if it's quality or not. And then if it is good, it will output the response. And if the answer is not good, it will tell the agent to try again. Answer wasn't good quality, send a new query to child agent. Obviously that's a very simple use case, but you could have different sort of filters going through. If you want to make sure things are sounding human-like, if you want to make sure, let's say you need actual requirements. So you need to make sure that, you know, number of guests is filled out. You need to make sure that the email is filled out. And if that stuff isn't filled out, it'll send it back and try again. So we'll show a quick example. We asked, can you search Wikipedia for information about Steve Jobs? It's going to hit the child agent, and obviously it's looking for the field called response. So once we get this information back, we'll go into the child workflow and we'll see exactly what happened. We'll see that it evaluated the answer as good or bad. So we got the answer back from Wikipedia. We'll go into the child agent, go to executions, and this is the one that just took place. Let's give it a sec to load up. So as you can see, the query existed, so it sends it off to the agent, then it sends it off to the OpenAI model to make sure it was good or not. In here, we got the acceptable response. The json.message.content equaled good, as you can see. So because it was good, it sent it off to the final response for our agent. And actually, we probably don't want the response to be done. We would have wanted the actual message coming back from the agent, which would have been this output. So this should have been json.output. But either way, that's sort of how talking to agents works. All right, tip number 3, we're gonna be talking about error workflows. So in N8N, you can set up error workflows so that way, if, you know, something goes wrong and it's an automated workflow, you'll get it. You can either get notifications about it, or you can send an email to a client, to a team, basically telling them that the error has happened and we're working on fixing it. So this is a fake sort of parent workflow. So it has options to send emails, some stuff like that. And one thing to know is if you want to set up error workflows, the parent one that you're checking for errors has to be active. So now switching over to the actual error workflow, we can see here that we have an error trigger. So you would just come in here, type error, and you can see the error trigger right there. So this workflow is going to execute whenever the parent workflow errors, and we'll— I'll show you how to set that up in a sec. But let's just grab a test event real quick. So right now we have like an example error message, all this kind of stuff. You can see how it's coming through. And then like in Telegram, we could test this step and we would see what's coming through, which is right here, um, error example workflow message, and you can set up like a link to the workflow. This is just stuff that I set up in case you want to be able to click on that and go into the workflow and see what happened. And then I also just have it set up to send an email that would say, you know, hey team, we received an error in the following workflow, we're working on resolving the issue, and you know, that sort of stuff. So let's go into the parent workflow real quick, and if you go to settings up here, we can see error workflow, and then you'll choose the error workflow that you set up. Obviously this workflow needs to start with an error trigger, So this is the one that we just looked at. We choose error handling and now we're good to go. So let's pull up our Telegram. We'll chat with this agent right here. We're just going to say hello. And as you can see, we're going to get that error workflow message back. Parent workflow, error demo, no prompt specified. And then that's why it errored. And also you can see, let's say we wanted to do this. We would once again say hello, and now it's going to error and say a chat model subnode must be connected. Because it has no brain. Then real quick, just pulling up that email that was sent off based on that previous error, which was the subject— we made it a chat model subnode must be connected. We received an error in the parent workflow, um, we're resolving the issue. And then let me just hop back into the actual error workflow. We'll go to executions, and let's look at the most recent one that just took place. As you can see, it automatically got triggered because it errored, and then it filled out the information right here in Gmail and then also within our Telegram. So super handy. And you can also connect an error trigger, you can connect multiple workflows to the same error workflow. So if you want one thing to be set up for every single time any workflow in your N8N instance errors, you can connect this to all your different active parent workflows. Okay, moving on to the next tip, we're going to be looking at the difference between question marks or pipe operators within sort of a variable call. So real quick, let's go over the difference. So we've got two pipes, two question marks. The pipes are going to be a logical OR. So you're going to put like, let's say you're referencing JSON.output, you'll put JSON.output and then you'll put two pipes and then a fallback value. So it's going to be looking for if this value over here, the JSON.output is falsy, it's just going to automatically grab that fallback value to make sure that there's no errors moving through. So this, like I said, the pipes are looking for something falsy. False values are false, zero, empty strings, or null, or undefined. So then in that case, it's going to use a fallback value. And we'll get into an example where I'll show this, the difference. And then the two question marks is actually looking for only missing information. So null or undefined, that's it. If something's zero or it's an empty string, it's still going to use that original value and it won't go to the fallback value. So the key difference here is pipes are for empty things and question marks are for null or undefined. So anything empty like a zero, you'll use pipes. Anything that could be null or undefined, you're going to use question marks. So in here we have this information, which is username is null, age is 0, email is empty. We'll test this workflow and we'll look at 3 different examples. So in this first one, we've got json.username is what we want to pull back, and if the username comes back null, then we're going to be using the fallback value of guest user. And so as you can see, both cases where we use the question mark or the pipe are coming back with guest user. This is because username is null is considered falsy, so the pipes are going to result to the false fallback value. And username is null, the question marks consider that actually null, of course, so it's going to use the fallback value. In the second example, we're using age, which is 0. So the pipes treat 0 as falsy, that's why it uses the fallback value of 18. And then the question marks, 0 is 0, it's not missing, it's not undefined, it's actually— there's information in the age field that's 0, so it doesn't have to fall back, it just uses what's there. And then finally we've got email. So we're using json.email, and actually I use close brackets or square brackets with the field because it's just another way you can reference things. And the pipes went to the fallback value of no email provided because email, there's nothing there. But the question marks went with the original value of email, which was empty, and it didn't have to fall back. And so the reason it's doing this, even though there's nothing here is because in the, you know, JSON we set up, email is— it exists. It's an empty string and it still exists. So that's why it just pulls it in for the question marks. But because it's an empty string, the pipe operators consider that falsy. And so because there's no email provided, that's falsy, it goes to the fallback value. So hope that makes sense. That's something that I recently discovered, could be definitely very useful if you're trying to maybe merge some data and you want to grab one or the other. And you can just basically check which one exists and then have it automatically pull in that one. So, um, yeah, cool tip there. All right, so the last tip before the bonus tip is using From AI when you're setting up AI agents and giving them tools. So if we come down to an AI agent here, obviously you're going to give them access to tools. And if you click on this plus, you can see that there's other tools already stored in here. So maybe if you wanted to take action in email or calendar, you wouldn't have to set up a whole nother workflow that does the Calendar actions, it's just going to happen right here. So let's say that we're grabbing a calendar tool, right? Um, and we're obviously going to connect our calendar. What we need to do to create an event is we need to give it a start time, an end time, and then we can add other fields like attendees. We can add, um, uh, the summary, which would be the title that shows up in the calendar event, and then we could add like a description. So let's leave it at this for now. And as you can see, it's going to say use the expression for from AI, and then you put a placeholder name so that the model, the AI model is going to automatically fill out start time, end time, all this kind of stuff based on the query that you feed into the AI agent. So I'm going to really quick just show an example, but if you want to get a more of a detailed breakdown of why this is so cool, then I'll tag a video right here where I sort of broke it down in, in more detail. But anyways, we'll come into here and we're going to be configuring this node. So for expression, We're going to reference fromai, which you can see is right here. And then all we have to do is put in quotes, start time. So then it's going to automatically fill in this information when we talk with this agent. We'll do the same thing for end time, in quotes, end time. And then we'll really quickly, I'll fill in the same thing with attendees, description, and summary. Okay, so I filled in the other stuff to automatically be filled in by the model. One thing I want to point out is let's say for description, it's not pulling it out right. You could come in here, add a comma, and then you can add a description of the key, which the key is description, and just say like a summary of the event. And now the model has more information on what it's looking to, what it's looking for to fill in the description for this event. Okay, and just to test it out real quick, we said create a meeting with John for December 2nd from 8:00 AM to 10:00 AM for a Project Panda discussion and work session. So this calendar event tool is going to take this query that we just sent it and it's going to automatically understand the start time, the end time, the attendees, the description, and the summary. So as you can see, this stuff got filled out really quick. And if we go to calendar, we can see we got a Project Panda discussion and work session with the right time, with the right summary, and with the description that was generated based on the model. So super cool tip, um, and it's really going to help out when you're, you know, giving agents tools. Although I wouldn't recommend giving this agent like all the actions. You don't want to maybe overload it with too many tools because then it, you know, the prompting can get confusing and stuff like that. Um, but it's super way, super cool way to get stuff up and running very quick. As you can see, that took like a minute. So real quick before the bonus tip, just wanted to say if you're finding this video useful, please consider giving it a like. It really helps me out. Also wanted to mention to check out my school communities. They will be linked down in the description. You know, we'll go more hands-on with real use cases, production-ready workflows, and live calls, stuff like that. Alright, that's it. I'd love to see you guys in there, but let's go on to that final bonus tip. Finally, the bonus tip. Really quick, just wanted to talk about referencing nodes, something that's really good practice to just get in the habit of for, you know, when you want to change your workflows later on. So as we know, when we have information, right, so in here we have a fruit, apple, vegetable, carrot. And so when we want to access this information, so I'm just going to grab a set field, all we have to do is, um, you know, you can drag it in, right? So if you drag in the fruit right here, we get JSON.fruit which come back, comes back with the answer of apple. And then let's just say we want to go veggies, or I guess it would just be veggie. But anyways, json.vegetable, and now we're referencing it because if we take $json.something, it's going to be pulling the information that was directly before it, right? So that's fine, it works well. But now let's say we realize, oh, okay, we actually want to do something with this data in between these two steps. So let's just say we wanted to grab an aggregate node. We're just going to put all data into a single list. So now we have— let's just say that did something cool for the rest of automation. So now we have this information coming back, and then if we come in here, right, we want to test the step, and it's not going to work because everything that we had previously referenced, referenced, which is json.fruit, it's now looking for fruit and vegetable within the aggregate node because that's directly before it. It's no longer the trigger that's directly before it. So now we'd have to come in here, the whole automation would break and we would obviously drag in the fruit here, which we still be able to get the same information back, but it's no longer just JSON.fruit, it's JSON.data01, or sorry, 0, and then.fruit. So if we were to always reference the nodes originally, so let's say get rid of this again. So we're coming back to this example. I don't know why I saved that, but anyways, we're coming back to this example. So instead of just pulling in from here, JSON.fruit, We want to actually define it by the node. So if we come in here, I don't know why it always does that. Okay, now if we come in here and then we reference the workflow, right? So now we're taking it from the actual node, which is when clicking test workflow, and then we do item.json.fruit. Now we're getting the same thing, which is referencing apple. And if we do the same thing down here, we will get, um, we want to reference the node.item $.json.vegetable. So now we're getting that information back. And then if we decide we want to throw something in here, once again, we'll just do an aggregate for the sake of the example, all items. Now we get this back, and if we test the step, we're still getting our information back because the set field knows to reference the node before aggregate, not just whatever's previously coming back. So that will make your workflows more, um, I don't know, I guess easier to troubleshoot or more sustainable when you're wanting to add things in between. And when you're wanting to make changes. So if you get in the habit of always referencing the specific node, even if this was, you know, that looks weird, but anyways, even if your information is coming directly beforehand, if you want to do, you know, JSON blank is easier when you just drag it right in. But if you actually can get into the habit of referencing the node, you'll be able to move these things around and it won't matter the order. You'll always be getting the information that you wanted to reference. All right, that's going to do it for this one. Really appreciate you guys taking the time to watch this one to the end. Let me know in the comments what else you want to see, and I will see you guys in the next video. Thanks.










