Question 1

How do loops work in n8n? Do you have to build one every time?

Accepted Answer

The answer here is usually the opposite of what people expect — which is exactly why it gets asked. "No, quite the reverse: you rarely need a loop in n8n. Nodes run automatically over every incoming item — five items into a Slack node means five messages. The most common beginner mistake is not knowing this and building loops by hand. An explicit loop is needed in three cases: Batching — sending items in chunks because of an API rate limit; that is what Loop Over Items is for, with a Wait between batches Pagination — with the HTTP Request node you build the loop yourself to walk a paginated response Repeat until a condition holds — connect the output back to an earlier node and stop it with an IF Conversely, when I want a node to run only once, I do not build a loop — I use Execute Once."

Question 2

When do you extract logic into a sub-workflow?

Accepted Answer

List the criteria and justify each in a sentence. "I extract in four cases. 1. Repetition — as soon as the same logic is needed in a second workflow. Copying means two copies; sooner or later they drift and a fix lands in only one of them. 2. Size — when the canvas no longer fits on screen and is hard to follow. It also reduces memory pressure. 3. A clear boundary — logic with a well-defined input and output is a natural module. "Enrich a customer profile from an email address", for instance. 4. A tool for an AI agent — if you want to give an agent your own logic, building it as a sub-workflow is the only route. One more advantage: sub-workflow executions do not count towards the plan's monthly execution limit, so splitting does not raise the bill on Cloud. I would also state the other side: extracting every small piece is bad too — debugging a chain of ten sub-workflows is harder than one canvas."

Question 3

How would you build a workflow that processes a large volume of data?

Accepted Answer

This question probes how you think about scale. Cover four directions. 1. Batching. Loading 100,000 rows into memory in one execution causes problems. I split with Loop Over Items — for memory as much as for rate limits. 2. Dropping unneeded data early. I put Edit Fields or Filter as early as possible. If 5 of 50 fields matter, carrying the other 45 to the end of the flow is pointless. 3. Splitting into sub-workflows. Moving heavy processing into a sub-workflow relieves memory pressure, because each call runs as its own execution. 4. A cursor and resumption. A long run can break halfway. I store the last processed point so a restart does not begin from zero. On self-hosted there is extra attention needed for execution-data retention and binary file handling — both are classic sources of memory trouble."

Tool	What for	Watch out for
Automatic iteration	The node runs once per item — nothing to build	Some nodes are exceptions (the Code node in "Run Once for All Items" mode, for one)
Loop Over Items	Batching; staying inside API rate limits	The node stops itself once every batch is processed — no IF needed
Wait	Waiting for a duration or until a point in time	For rate limits, the wait goes between batches
Execute Sub-workflow	Extracting logic into a separate workflow and reusing it	If the sub-workflow has errors, the parent cannot trigger it
Merge	Combining branches or streams from different sources	Choose the right mode (append vs a join key)

Loops, Wait and sub-workflows

📚 Sources and documentation