Hi, I’m reposting this here because I was advised that this category is a better fit.
I’m trying to recreate in n8n a workflow that I previously built in Make.com using iterators.
In Make, the logic was fully sequential:
first one parent record,
then that parent’s child records one by one,
and only after all child records of that parent were finished did the scenario move to the next parent record.
This is very important for my case, because I need to preserve both:
the correct parent-child relationship,
and the sequential order of processing.
So I do not want:
all parent records processed at once,
or all child records processed at once.
What I need is:
process one parent record at a time,
inside it process its child records one by one,
keep the correct context for each child record,
and move to the next parent only after finishing all child records of the current parent.
In Make, I handled this with iterators on nested arrays.
In n8n, I was told that the equivalent is Loop Over Items, possibly with a second Loop Over Items inside it.
Would that also ensure that the child items are processed sequentially and not all at once?
If yes, what is the cleanest way to build that in n8n?
yeah loop over items is the right equivalent. the thing is it naturally does sequential processing when you nest them — first loop processes one parent item, then the inner loop handles all its children one by one before moving to the next parent. we used this exact pattern for a similar workflow once where order mattered, and it preserved the parent-child relationship perfectly. one thing though: make sure your child data is actually an array in each parent record, otherwise the inner loop won’t have anything to iterate over. what’s your data structure look like exactly?
Looping can actually be tricky in n8n especially with nested loops. Nested Loop Over Items can in theory work, but the wiring is less intuitive than Make’s iterators and it is easy to get it wrong so it is worth it to note a couple of approaches depending on your data structure.
If the children are already embedded as an array field for each parent(parent.children), the most reliable way to do this is actually using a single Loop Over Items for parents, then a code node that iterates the children with a standard Javascript “for of” loop.
You can still use a nested Loop Over Items if you prefer. The thing to pay attention to is the inner loops entire branch needs to complete BEFORE the outer loop advances. It can be done but you need to be careful about where nodes connect back to, it can break accidentally.
You could also utilize sub-workflows if you want, having the main flow being for the parent and the sub workflow handling each child. It may take longer but has much cleaner logic.
I am still trying to understand the best way to build this in n8n. It looks great and seems to offer more possibilities than Make, but I am struggling with reading the outputs and I am not sure if I built the workflow correctly.
First, the parent loop goes through the rooms and for each room checks whether there are any registered participants. If there are, the workflow continues and checks the product / group. After that, I need to iterate through the participants one by one, check whether they already exist in the CRM, and if not, add them. Only after finishing this whole process for one room should the workflow move to the next room, and continue like that until the end of the parent list.
I also had to add Summarize, because without it the next step was running once for every registered person, while I only wanted it to continue once per room.
What confuses me the most is that in Loop Over Items the output shows fields as undefined, even though those values exist in earlier nodes. Because of that, I am not sure whether the workflow is actually wrong, or if I am just misunderstanding how n8n displays loop outputs.
I’d be careful with assuming nested Loop Over Items always behaves like Make iterators. In n8n the loop node keeps state, so an inner loop can skip on the next parent if it isn’t reset/wired exactly right.
The cleanest pattern is usually:
Parents → Loop Over Items, Batch Size = 1
→ Execute Workflow, wait for completion
In the child workflow:
Split Out parent.children while keeping the parent id/fields
→ Loop Over Items, Batch Size = 1
→ process each child
This guarantees: one parent at a time, children one by one, and the next parent only starts after the child workflow finishes. If you keep both loops in the same workflow, set Batch Size = 1 on both and use the inner loop Reset option carefully, otherwise the inner loop may keep its completed state.
Thank you, this is very helpful. I’m currently studying Execute Workflow, because I just noticed that loop-in-loop in n8n can indeed be problematic, as you mentioned.
If I understood correctly, the problem is that the inner loop may keep its state and not start correctly for the next parent item, so Execute Workflow is a safer option.
It’s not that nested Loop Over Items can’t work, but the inner loop has its own state, so if it is not reset/wired correctly it may not start cleanly for the next parent.
Using Execute Workflow is safer because each parent triggers a fresh child-processing run. With “wait for completion” enabled, the outer parent loop will only continue after all children for the current parent are finished.
So for reliability and readability, I’d use the sub-workflow pattern unless you specifically need everything in one workflow.