Documentation
Jira shows one level of the hierarchy at a time. An epic lists its children, a story lists its subtasks, and nothing shows the shape of the whole thing — let alone work spanning several projects. Multi-level hierarchy is a Premium feature, so teams on Standard either upgrade the entire site or work without it.
• Reads Jira's real hierarchy and never invents one. Nothing is stored in the app, so the tree stays correct in JQL, boards and reports. • A Hierarchy section on every work item: its parent, top-level ancestor, child count, and the first few children by name. • The full tree — ancestors above, children and subtasks below, with status, assignee, story points and a progress rollup. • Across projects from any JQL filter, which Jira cannot do natively. • Children load only when you open a branch, so a 1,000-child epic opens instantly. • Team-managed and company-managed projects both work; so does Jira Service Management. • Runs on Atlassian — no servers, nothing stored, read-only.
See where any work item sits - A Hierarchy section on every work item shows its parent, its top-level ancestor, how many children it has and the first few by name — without leaving the item or opening anything else.
Cross-project hierarchies from any JQL - Jira has no native cross-project hierarchy view. Enter any JQL filter — a project, a label, a release — and get one tree spanning every project you can see.
Numbers that tell you the truth - Children load only when you open a branch, so a thousand-child epic opens instantly instead of stalling your work item view. The rollup always says what it covers.
The app is read-only. It shows hierarchy; it does not create or change links.
Levels above epic are not supported in v1 — Jira Standard has no parent above epic, and the app does not invent one in its own storage.
Rollups cover loaded descendants unless the panel says "complete".
Story points appear only where the field holds a value.
Issues the viewer cannot see in Jira are shown as Restricted, never silently hidden.
When a licence lapses the app stops showing hierarchies entirely — it does not fall back to a reduced free view.
In Jira Service Management the tree is only as deep as the project's issue types allow — JSM ships no epic-level type by default, so a service project is request → sub-task until an admin adds one.
Email us and we will reply. Include the work item key, whether the project is team-managed or company-managed, and what the panel showed — a screenshot of the Hierarchy panel is usually enough. If the tree looks wrong, the issue's parent field in Jira is what the app reads, so that is the first thing to check.