Skip to main content

What are sub-workflows?

Sub-workflows are helper workflows called by parent workflows via n8n’s Execute Workflow node. They encapsulate reusable logic (PDF generation, data parsing, API calls) and are invisible to end users.

Key rules

config.ts definition

Sub-workflow entry

Parent workflow entry

The parent workflow lists the sub-workflow’s integrationUids in its own integrationUids array (integration inheritance).

Sub-workflow JSON

Entry node (Execute Workflow Trigger)

Accessing input data

Parent workflow: calling the sub-workflow

Execute Workflow node

Key points:
  • workflowId uses the SUBWKFL placeholder with the sub-workflow’s workflowTemplateId
  • waitForSubWorkflow: true makes the parent wait for the sub-workflow to complete
  • executionId and executionSecret are forwarded from Codika Init for platform tracking

Passing execution metadata

If the sub-workflow uses Codika Upload File, it needs the parent’s execution metadata:

Parent sends metadata

Sub-workflow uses metadata in Upload File

SUBWKFL placeholder format

The workflowTemplateId in the placeholder must exactly match the workflowTemplateId in the config. Examples:
  • {{SUBWKFL_text-processor_LFKWBUS}}
  • {{SUBWKFL_pdf-generator_LFKWBUS}}
  • {{SUBWKFL_email-parser_LFKWBUS}}
At deployment time, this is replaced with the actual n8n workflow ID.

Deployment order

Sub-workflows are deployed before parent workflows automatically. The platform resolves the dependency graph and deploys in the correct order. No manual ordering is needed.

Validation

The CLI checks sub-workflow patterns: