Hierarchical / Grouped Execution History for Orchestration-Based Workflows

[Nskha]

The idea is:

Add a hierarchical grouping view to the Execution History (both the global Overview page and per-workflow execution lists) that visually groups parent workflow executions with their sub-workflow executions in a collapsible tree structure, instead of listing every execution as an independent, flat row.

When a parent workflow (Workflow A) triggers sub-workflows B, C, D, E via the Execute Sub-workflow node, all of these currently appear as separate, unrelated rows in the execution history. The proposal is to:

1. Group parent + child executions in a collapsible tree, with the parent row showing an expandable indicator (/▼) and a badge like ⧉ 6 sub-executions
2. Show aggregate metadata on the parent row: total run time across the tree, number of children, aggregate status (all success / partial failure / failed)
3. Add a toggle: “Group orchestration executions” to switch between the current flat view and the new grouped view
4. Use tree-line indentation (├─ └─) to show parent → child → grandchild depth within the grouped view
5. Add a filter option: “Hide sub-workflow executions” to only display top-level/root executions (similar to Temporal’s “Show Child Workflows” toggle)

(Above: Left panel shows the current flat execution list where 7+ related executions appear as independent rows. Right panel shows the proposed grouped view where the parent execution collapses its children into a tree.)

My use case:

I build orchestration-heavy automation systems where a single logical operation (e.g., “Delete a marketplace listing”) triggers a chain of 5-10+ sub-workflows:

[CORE]~[Marketplace Router]~[Delete]~[Single Item]     ← Parent (orchestrator)
  ├─ [API]~[Marketplace]~[****]~[Delete Account]       ← Sub-workflow 1
  ├─ [API]~[Marketplace]~[****]~[Delete Acc.]  ← Sub-workflow 2
  ├─ [API]~[Marketplace]~[****]~[Delete Account]          ← Sub-workflow 3 (has own children)
  │   ├─ Sub-workflow: User Verification                  ← Grandchild
  │   ├─ Sub-workflow: Deactivate Token                   ← Grandchild
  │   └─ Sub-workflow: Record Deletion Audit              ← Grandchild
  ├─ [CORE]~[Marketplace Router]~[Delete]~[Single Item]  ← Sub-workflow 4
  └─ [API]~[Marketplace]~[Airtable Manager]~[Delete...]  ← Sub-workflow 5

Currently, all of these show up as independent rows in the execution history, making it:

• Impossible to understand at a glance what happened — I see “67 production executions” but the actual number of logical operations is far fewer; the count is inflated by sub-workflow noise
• Extremely difficult to debug failures — when one sub-workflow in a chain fails, I have to manually cross-reference execution IDs and timestamps to find which parent triggered it and which siblings ran alongside it
• Cluttered and noisy — the execution list becomes dominated by sub-workflow rows that obscure the actual top-level business operations

The “View sub-execution” link inside the Execute Workflow node (added in v1.69.0) is helpful for navigating one-at-a-time between parent ↔ child, but it doesn’t solve the core problem: the execution list itself has no concept of grouping.

(Above: Real execution history from my n8n instance, all rows are listed independently with no visual indication of which executions belong to the same orchestrated operation.)

(Above: The tooltip already mentions “Hierarchical view of orchestration-mode executions” — the concept exists but isn’t fully implemented in the execution list.)

I think it would be beneficial to add this because:

1. The backend data already exists

Since v1.69.0, the Execute Workflow node stores parentExecution metadata containing executionId and workflowId on child executions. The relationship graph is already persisted — it just needs to be surfaced in the UI.

2. Every major workflow orchestration platform has solved this

• Temporal has a “Show Child Workflows” toggle and a Relationships tab that displays the full parent/child hierarchy as a tree. They also allow viewing child workflow timelines inline without navigating away.
• Prefect links every child flow run to its parent via parent_task_run_id and shows a dedicated “Sub Flow Runs” tab when viewing a parent execution.
• Apache Airflow uses Task Groups in the Grid View that can be expanded/collapsed, showing nested task hierarchies with duration bars.

n8n is increasingly being used for complex orchestration (multi-agent AI systems, microservice-style workflow architectures, marketplace automation), but the execution observability hasn’t kept pace.

3. Community demand

This has been requested multiple times across the community:

• “Link Sub Workflow with Parent Workflow” (2022) — noted that parentExecutionId exists in the codebase but isn’t fully used
• “Easy access to sub workflows (drill-down)” (2024) — requested ability to view sub-workflow progress and errors without manually navigating
• “Access top-level workflow ID and execution ID in subworkflows” (2025) — requested traceability back to the root workflow
• “Any way to get complete execution cycle of workflow→sub workflows?” (2025) — confirmed the API response is “flat” with no native parent-child linking

4. It reduces noise and improves execution count accuracy

The Overview dashboard’s “Prod. executions” counter becomes misleading when most executions are sub-workflows. Grouping would let users understand their actual operation count vs. the total execution count.

Any resources to support this?

How other platforms handle this:

Platform	Feature	Description
Temporal	Show Child Workflows toggle	Toggle to hide/show child workflows in the execution list; Relationships tab shows full parent/child tree
Temporal	Inline child timeline	View child workflow timeline directly from parent’s execution detail (Compact & Timeline views)
Prefect	Sub Flow Runs tab	Each parent flow run has a “Sub Flow Runs” tab listing all child flows with their status; parent_task_run_id links relationships
Airflow	Task Groups in Grid View	Collapsible task groups in the grid view showing nested hierarchy with duration and status

n8n internal references:

• v1.69.0 parentExecution metadata: The Execute Workflow Trigger node already stores metadata.parentExecution.executionId and metadata.parentExecution.workflowId — this is the exact data needed to build the hierarchy
• Execution Public API: The /executions endpoint returns flat results; adding a parentExecutionId filter or include=children parameter would complement the UI change

Suggested implementation approach:

1. Query enhancement: When fetching executions, optionally JOIN on parentExecutionId to build a tree structure
2. UI grouping: Render parent rows with expand/collapse controls; indent child rows with tree lines
3. Toggle: Add “Group by orchestration” toggle (default off for backward compatibility)
4. Filter: Add “Hide sub-workflow executions” filter to show only root-level executions
5. Badge: Show ⧉ N sub-executions badge and aggregate status on parent rows

Are you willing to work on this?

I would be willing to help test, provide feedback, and contribute to the UI specification. The core backend data (parentExecution metadata) is already there, this is primarily a frontend/UI enhancement to the execution list component.

[Benjamin_Behrens]

This resonates a lot — once you have orchestration-heavy workflows where a single logical operation triggers 8-10+ sub-workflows, the flat execution list becomes really hard to parse quickly. The parentExecution metadata is already in the backend, so this feels like a frontend enhancement that would have an outsized quality-of-life impact. The “hide sub-workflow executions” toggle alone would already be a huge win for anyone doing multi-agent or microservice-style automation.