Overview
With the introduction of multi-level subitems, it's much easier to model real-world project hierarchies. However, automations do not yet account for these hierarchy levels and always default to referencing the main (top-level) item. This limits the usefulness of automations as boards become more complex.
I’m requesting the ability for automations to recognize an item’s hierarchy level and reference the immediate parent item, regardless of depth.
The Problem
Today, when an automation is triggered on a subitem or sub‑subitem, it can only reliably pull data from the main item. There is no way to:
Identify whether an automation is running on a main item, subitem, or deeper level
Reference the parent subitem when working at lower levels in the hierarchy
As a result, automations do not scale well for structured project workflows that rely on naming conventions, phased work, or nested tasks.
Proposed Enhancement
Introduce a system-level way for automations to understand item hierarchy, such as:
A built-in column or variable that identifies the hierarchy level of an item (e.g., Level 1, Level 2, Level 3, etc.)
Or automation logic that allows actions like:
“Reference the immediate parent item” rather than always referencing the main item
Example hierarchy levels:
Level 1 – Main Item (Parent)
Level 2 – Subitem (Child)
Level 3 – Sub‑subitem (Grandchild)
Level 4 – Sub‑sub‑subitem (Great‑grandchild)
Example Use Case
Structure:
Project ABC (Main Item)
Project ABC: Research (Subitem)
Project ABC: Research – April 2026 (Sub‑subitem)
How this would work with hierarchy-aware automations:
A user creates a subitem and types “Research”
An automation combines the main item name and user input →
“Project ABC: Research”
A user creates a sub‑subitem and formula column returns the current month/year, “April 2026”
An automation references the immediate parent subitem name, not the main item
Resulting name →
“Project ABC: Research – April 2026”
Currently, step 2 isn’t possible because automations always pull from the main item