Adding Initiatives Above Epic in Jira: The 2026 Guide
Four methods get you an Initiative level above Epic: upgrade to Jira Premium and configure a custom hierarchy level in Plans; fake the level in Standard with a custom issue type and parent-link field (cheap but fragile); install a PPM app like Structure or BigPicture; or use Foundation Flex Items to build a virtual Initiative layer without touching Jira's schema.
Why does Jira top out at Epic by default?
Jira Cloud ships a three-level hierarchy: Sub-task, Story / Task / Bug, and Epic. That's the whole ladder. For a single team planning a quarter, it's usually enough. For a VP looking across six teams and a year-long goal, it falls apart fast — hundreds of Epics with no way to group them into outcomes.
Atlassian gated custom hierarchy levels above Epic behind Premium and Enterprise. On Premium, an admin can add levels (Initiative, Theme, Portfolio) and use Plans to roll up progress. On Standard, the hierarchy-level screen is read-only — you can create an Initiative issue type, but not make it a real parent of Epic. That cliff is why four workaround methods exist in 2026.
Method 1 — Premium Plans custom hierarchy level
The Atlassian-native path. Upgrade to Premium, open Settings > Issues > Issue type hierarchy, and add a level named Initiative. Open Plans, scope it to your projects, and Initiatives appear at the top of the timeline with child Epics nested beneath.
What's good: first-party, so reports, dashboards, automation rules, and the mobile app all understand the level. Cross-project rollup is built in. What's painful: Premium is roughly 2x Standard per user, site-wide — you're upgrading the whole Jira bill for one capability. Plans is a roadmap view: no dependency arrows, no critical path, no baselines, no drag-to-reschedule. Need a real Gantt? You'll still need a Marketplace app on top.
Method 2 — Custom issue type in Standard tier (the cheap but fragile way)
The “fake it” path. On Standard, a Jira admin can create a new issue type called Initiative, then add a Parent Link custom field on Epic pointing at it. JQL like "Parent Link" = INIT-14 finds all Epics under an Initiative.
What's good: zero incremental cost, ten minutes of admin work. For a small team with one or two Initiatives and tolerance for manual reporting, it can be enough. What's fragile: not a real hierarchy level, so Jira's hierarchy-aware features don't work. Plans is Premium-only, so it doesn't exist for you. Status, date, and story-point rollups don't happen automatically — you keep the Initiative in sync by hand. The parent-link relationship doesn't cross projects unless you configure the field site-wide. Works at one team, breaks at five.
Method 3 — Structure or BigPicture hierarchy
Marketplace PPM apps solve the hierarchy-above-Epic problem by ignoring Jira's hierarchy configuration entirely and storing their own tree in their own data layer. Structure (by Tempo) builds a tree where each node is a Jira issue or a Structure folder — drop a folder called “Payments Initiative” above your Epics and it handles the rollup. BigPicture (by Appfire) uses nested “Boxes.” Both run on any Jira tier.
What's good: no Jira upgrade, cross-project by default, real Gantt with dependencies, rich reporting, large install bases. What's painful: both have steep learning curves and price ladders that climb fast at enterprise scale. Structure's Gantt is a separate add-on billed on top of Structure itself. BigPicture bundles Risks, Resources, and SAFe constructs — you pay for the whole suite regardless.
Method 4 — Foundation Flex Items (no Jira schema changes)
Foundation takes the same overlay approach as Structure and BigPicture with a focus on making the overlay cheap and fast. Its equivalent of a Structure folder is a Flex Item: a hierarchy node in Foundation storage (Forge SQL) that can sit above, below, or beside Jira issues in a Lens.
Create Flex Items at the top of a Lens (one per Initiative) and attach Epics as children via Bulk Add or a Sync Agent with a JQL query. Foundation rolls up child dates, status, and story points automatically. Jira itself is unchanged — no new issue type, no custom field, no admin work. Uninstall Foundation and your Jira looks exactly as before.
What's good: works on Standard, takes minutes, cross-project by default, free tier for up to 10 users. The Initiative layer carries its own fields (budget, target quarter, exec sponsor) without polluting Jira's schema. What's honest: Foundation is the newest of the four. The MVP caps a Lens at 1,000 issues, is Cloud-only, and formulas land Q1 2027. For teams that just need Initiative-above-Epic without Structure/BigPicture complexity or a Premium upgrade, it's the fastest path.
Step-by-step — adding an Initiative layer with Foundation
End-to-end flow for Method 4. Total time: about 30 minutes for a first Initiative layer across two or three projects.
- Install Foundation from the Atlassian Marketplace. In Jira, open Apps > Explore more apps, search for Foundation, and install. Free tier covers up to 10 users. No Jira admin tier change needed — Foundation runs on Standard, Premium, and Enterprise identically.
- Create a new Lens and name your Initiative layer. Open Foundation > New Lens. Give the Lens a name (e.g., "FY26 Initiatives"). Add a Flex Item at the root level and name it Initiative — this becomes your custom hierarchy level above Epic. No Jira schema change, no Premium required.
- Add Initiative Flex Items and attach Epics as children. Create one Flex Item per Initiative (e.g., "Checkout redesign", "Data platform Q2"). Use Bulk Add by Issue Key to paste lists of Epic keys, or configure a Sync Agent with a JQL query (like "project = PAY AND issuetype = Epic") to auto-attach Epics as children. Epics can span multiple Jira projects.
- Roll up dates, status, and story points to the Initiative level. Foundation automatically rolls up start date, due date, and status from child Epics to their parent Initiative Flex Item. Switch on the Gantt view to see Initiative-level timeline bars. Share the Lens with stakeholders via the Share button — view, edit, or control access levels are granted per user or group.
Which method fits your tier and org size?
The four methods differ on Jira tier required, schema change, cross-project reach, cost, and migration effort if you pick wrong.
| Method | Jira tier required | Schema change | Cross-project | Cost | Migration effort |
|---|---|---|---|---|---|
| Premium Plans custom level | Premium or Enterprise | Yes — new hierarchy level | Yes | ~2x Standard per user, site-wide | Built in; no migration |
| Custom issue type (Standard) | Standard | Yes — new type + custom field | Only if custom field is site-wide | Free (already in Standard) | Moderate — issue keys survive |
| Structure or BigPicture | Any (Standard OK) | No — external hierarchy | Yes | Per-user; add-ons extra | Export via CSV or API |
| Foundation Flex Items | Any (Standard OK) | No — Forge SQL overlay | Yes | Free up to 10 users; per-user above | CSV import + Bulk Add by key |
Rough rules. Under 10 users, experimenting: try Foundation's free tier — fastest path to a working Initiative layer. Already on Premium: use Plans custom hierarchy — you already paid for it. Deep SAFe or resource management: BigPicture. Very large site, dense cross-project dependencies: Structure. Tiny team, one or two Initiatives, manual-rollup tolerance: the custom issue type trick can buy a few quarters.
For the broader hierarchy picture, see the pillar on Jira hierarchy beyond Epic. If you specifically want to avoid the Premium upgrade, read custom hierarchy levels in Jira without Premium. For a direct head-to-head, see Plans vs Structure vs Foundation.
Frequently asked questions
Can I create a hierarchy level above Epic in Jira Standard tier?
Not a true hierarchy level — custom hierarchy configuration is Premium/Enterprise only. On Standard you can create a custom issue type called Initiative and link Epics via a parent-link field, but Plans is Premium-only and reporting treats it as a flat issue type. Teams on Standard who need a real hierarchy level install a PPM app like Structure, BigPicture, or Foundation.
What is the difference between an issue type and a hierarchy level?
An issue type is a label (Bug, Story, Task, Epic). A hierarchy level is a rung on Jira’s parent-child ladder. Two issue types can share a level (Story and Task are both Story-level). Creating an issue type is free on Standard; adding a new hierarchy level requires Premium.
Does Foundation require Jira Premium to add an Initiative layer?
No. Foundation runs on Standard, Premium, and Enterprise identically. Flex Items live in Foundation storage (Forge SQL), not in the Jira issue database, so adding Initiatives above Epic doesn’t touch Jira’s schema.
If I build a fake Initiative layer with a custom issue type, can I migrate later?
Yes. The custom issue type lives in Jira as a normal issue, so keys and custom fields survive. Moving to Foundation, Structure, or BigPicture means rebuilding parent-child links in the new tool — Foundation’s CSV Import accepts a parent-key column, and Bulk Add by Issue Key seeds a Lens from a pasted list of INIT keys.
What is the cheapest way to add Initiative-level reporting cross-project?
Usually: install a PPM app on Standard rather than upgrade Jira itself. Jira Premium is roughly 2x Standard per user, site-wide. A per-user PPM app (Foundation, Structure, BigPicture) typically costs far less than the Premium delta and gives you cross-project rollup plus a real Gantt.