Hierarchy panel (Parent → Children)

The admin panel defines which issue types can be children of which parent. This models levels and containers (OKR, SAFe, Initiative → Epic → Story, or another site tree). The model is a tree, not a linear list: one parent can have several child types (for example Epic → Story, Bug, and Task). Sub-task types can only be children: they are leaves.

The configuration is saved and restored (Forge storage). The Gantt uses these rules, together with the Parent Element field, to nest bars.

How to configure the rules

1. Open the Stratify admin page (Apps → Stratify, or the app's admin entry).
2. You will see the list of issue types available on the site.
3. In the Parent → Children editor or modal, choose a parent type and the allowed child types.
4. Review the preview of the resulting tree.
5. Save. Without a saved configuration, the panel shows an empty state with guidance for the first save.

Sub-tasks in the hierarchy

Sub-task types appear in the catalog with the Sub-task badge.

• They can be configured as children of a parent type.
• They cannot have children: they are leaves. The row does not offer child configuration and saving rejects that relationship.
• In the Gantt, a sub-task always hangs from its Jira native Parent, even when Parent Element has a value.
• If the Parent is not in the plan JQL, the sub-task appears under No parent.

To see the breakdown in the Gantt, include the sub-task type as a child and make sure the plan JQL returns those sub-tasks.

Best practices

• Start with the highest-level container in your model (Initiative, Objective, Portfolio, and so on).
• Allow only the child types the team actually uses; an overly broad tree makes the Gantt harder to read.
• Include the sub-task types the team uses if you need to see the work breakdown in the Gantt.
• If the hierarchy does not have the space name yet, the Space column shows Espacio {id}.
• After saving, check a test plan: bars must nest according to Parent Element, Jira's native Parent, and these rules.

Permissions and the Gantt

JQL ingestion and sync run as the user who uses the Gantt. The user needs permission to:

• View the work items in the JQL.
• Edit the dates (and agreed fields) of the work items that will be synced.

A user without edit permission can view the plan, but sync will fail on those work items. The sync summary keeps failed drafts with the error.

When the hierarchy is ready, continue with the User Guide.