n8n Execute Workflow-nod: bryt ut återanvändbara delflöden och anropa dem från flera automationer

Det är lätt att starta med ett enda n8n-workflow. Sedan lägger du till en branch. Sedan en till. Efter tre veckor är du den person som förklarar ett diagram med tolv rader och tjugo noder för ett nytt teammedlem.

Execute Workflow-noden löser det problemet.

Vad noden faktiskt gör

Execute Workflow-noden anropar ett annat n8n-workflow som om det vore en funktion. Föräldraworkflowen skickar in JSON-items, delflödet bearbetar dem och returnerar JSON-items tillbaka. Ur förälderns perspektiv är det bara en nod till i kedjan.

Det enda kravet: delflödet måste ha en “Execute Workflow Trigger”-nod som ingångspunkt. Utan den vet n8n inte hur det ska ta emot anrop utifrån.

Synkront vs asynkront

Det finns två varianter av noden och de är inte utbytbara.

Execute Workflow (synkront): föräldraworkflowen pausar och väntar tills delflödet är klart. Du får tillbaka data. Fel i delflödet sprider sig uppåt — föräldraworkflowen stannar med ett tydligt felmeddelande som pekar på det delflöde som kraschade.

Execute Workflow Trigger (asynkront): föräldraworkflowen skickar iväg anropet och fortsätter utan att vänta på svar. Du får ingen data tillbaka. Fel i delflödet loggas separat och syns inte i förälderns exekveringshistorik om du inte lagt upp explicit felhantering i delflödet.

Tumregel: synkront när du behöver svaret, asynkront när du inte bryr dig om det.

Det praktiska arkitekturmönstret

Den vanligaste användningen är ett centralt notifikations-hub-workflow. Alla dina andra workflows som vill skicka ett Telegram-meddelande, ett Slack-ping eller ett e-postlarm anropar samma delflöde med en standardiserad payload:

{ "channel": "telegram", "message": "Workflow X lyckades" }

Det ger dig:

• En enda plats att byta notifikationskanal (ändra Telegram-noden i hubben, alla workflows uppdateras)
• Konsekvent felhantering (delflödet vet hur det ska hantera ogiltiga payloads)
• Renare föräldarworkflows (ersätter fyra noder med en anropsrad)

Credentials och scope

Delflödet körs i förälderns credential-scope. Om föräldraworkflowen har tillgång till en Postgres-credential kan delflödet använda den utan att den behöver tilldelas separat. Det är praktiskt men kräver att du är medveten om access-kontrollen — ett delflöde som anropas från ett publikt webhook-workflow har samma credential-access som det workflow som anropade det.

Felsök med exekveringshistoriken

Vid synkrona anrop kan du följa exekveringskedjan: öppna det misslyckade föräldraworkflowen i exekveringshistoriken, klicka på Execute Workflow-noden, och se länken till delflödets exekvering. Det tar dig direkt till den nod i delflödet som kraschade. Du behöver inte gissa.

Vanliga frågor

Kan ett delflöde anropa ett annat delflöde?

Ja, du kan kedja Execute Workflow-noder. Var uppmärksam på cirkulära anrop — n8n tillåter det inte och kastar ett fel vid körning.

Behöver varje delflöde egna credentials?

Nej. Delflödet ärver förälderns credential-scope automatiskt. Du behöver bara tilldela egna credentials om delflödet körs fristående (t.ex. via ett eget schema-triggers) och inte via föräldraanrop.

Hur testar jag ett delflöde isolerat?

Trigger-noden i delflödet (Execute Workflow Trigger) kan ta emot testdata direkt via “Execute Step”-knappen i editorn. Ange en JSON-payload som mock för föräldrarns input och kör delflödet fristående.