Jira Plans vs Structure vs Foundation: Hierarchy Models Compared

Three realistic ways to build hierarchy above Epic in Jira Cloud: Jira Plans (tier-locked, native, rigid), Tempo Structure (deeply flexible, Connect-based, mature), and Foundation Lenses (Forge-native, Flex Items, newer). They produce similar-looking hierarchies with very different data models, extensibility, and price curves. Here's how to choose.

What exactly are we comparing?

All three tools answer the same question — “how do we group Epics under something bigger, like an Initiative or a Theme?” — but each uses a fundamentally different data model to do it.

Jira Plans (the Premium-bundled feature formerly known as Advanced Roadmaps) extends Jira's own issue-type hierarchy. You configure new issue types (say, Initiative) and place them above Epic in the hierarchy settings. Every node is a real Jira issue. Tempo Structure is a Connect-based Marketplace app with ~14K installs that maintains its own parent-child database on top of Jira issues; hierarchy nodes can be issues or “folders” that exist only inside Structure. Foundation Lenses is a Forge-native app that stores hierarchy in Forge SQL and introduces Flex Items — non-issue nodes that live only inside Foundation.

The tradeoffs cluster around five dimensions: depth (how many levels deep), data model (Jira-native vs app-owned), cross-project scope, rollups (aggregation across children), and portability (what happens when you leave). No single tool wins every dimension. The right choice depends on which dimensions matter most to your program.

How does Jira Plans configure hierarchy? (Premium tier)

Jira Plans is bundled with Jira Premium and higher tiers. On Jira Standard or Free, Plans isn't available at all — the menu item appears but the feature is locked. This is the first and most significant constraint: Plans is a tier upgrade, not a Marketplace install.

When you do have Premium, the hierarchy configuration lives under Jira admin → Issue types → Issue type hierarchy. By default, Jira ships with three levels: Subtask → Story/Task → Epic. Premium lets you add levels above Epic — typical setups add “Initiative” at level 1 and optionally “Theme” at level 2. Each level is tied to a specific issue type, and every node is a normal Jira issue with full CRUD, workflow, and permission behavior.

This is the model's biggest strength and its biggest constraint. Strength: Initiatives and Themes are real Jira issues. They show up in JQL, in the Jira REST API, in reports, in automations, and in any other app that reads Jira issues. There's nothing to translate. Constraint: the hierarchy shape is rigid. You can't have a Theme containing another Theme (no arbitrary nesting), and every node must be a fully-configured issue type with screens, workflow, and notification schemes. Adding a new level means schema work across potentially hundreds of projects. See our guide on custom hierarchy levels without Premium for alternatives if you're not on Premium.

How does Tempo Structure build hierarchy? (parent-child positions, generators)

Tempo Structure takes the opposite approach. Rather than modifying Jira's own hierarchy, Structure maintains its own parent-child table in a Connect-backed database. Every row in a Structure is a position — an ordered pointer to a Jira issue (or a Structure-only folder) within a particular tree. The same Jira issue can appear at multiple positions in multiple Structures, or even multiple times inside one Structure.

This independence from Jira's issue-type hierarchy is the source of Structure's famed flexibility. You can stack any issue under any other issue regardless of their types. You can introduce folders with names like “Q2 Priorities” that aren't issues at all. You can go dozens of levels deep. Nothing in Jira needs to change to support any of this, because Structure isn't touching Jira's hierarchy — it's running its own parallel one.

Structure also pioneered generators, which are rules that automatically insert issues into a Structure based on JQL or parent-child relationships. An “Insert JQL” generator pulls all issues matching a query; an “Extend with children” generator walks down Jira links. The generator pattern is powerful enough that both Foundation and newer tools have adopted variants of it — Foundation's Sync Agents are directly inspired by Structure's generators.

How does Foundation Lens build hierarchy? (Flex Items + Sync Agents)

Foundation is a newer Forge-native app that borrows the best of both models. Like Structure, Foundation maintains its own hierarchy in its own storage (Forge SQL) — so it doesn't require Premium and doesn't depend on configuring Jira issue types. Like Plans, Foundation tries to keep as much hierarchy-as-Jira-issues as possible so the data stays portable.

The key primitives are Lenses (views over hierarchies), Flex Items (non-issue nodes that live only in Foundation — roughly analogous to Structure folders), and Sync Agents (generator-like rules that populate a Lens from JQL). A typical setup: a Lens called “Q2 Roadmap” contains top-level Flex Items for each Initiative, with a Sync Agent under each Flex Item that pulls matching Epics via JQL. Epics then extend to their Stories/Tasks via child-extend sync agents.

The MVP cap of 1,000 issues per Lens is a genuine ceiling. That's an architectural choice — Foundation rebuilds the Lens in memory from Forge SQL on each load — not a licensing gate. It will rise in future releases, but today it means Foundation isn't the right fit for enterprise programs that routinely render 10,000-issue views. It's aimed at program-level portfolios (a few hundred to a thousand issues) where hierarchy flexibility matters more than raw scale. Foundation also does not ship a user-facing formula engine in the MVP — rollups are pre-defined (count, sum of story points, earliest start, latest due), not user-authored.

How do rollups differ across the three?

Rollups are aggregations that flow up the hierarchy — “sum of story points across all children,” “earliest start date across all descendants,” “percent complete rolled up from leaf issues.” All three tools do some rollup, but they do it very differently.

Jira Plans rolls up dates (earliest start, latest due) and story points for the issue types configured in the hierarchy. It does not support custom-formula rollups. If you want to roll up a custom field or compute a derived value, Plans can't do it — you need an external reporting tool.

Tempo Structure is the deepest of the three on rollups. Its formula engine lets you define arbitrary calculated columns that reference parent and child values, making it possible to express things like weighted completion, budget remaining, or custom health scores. This is one of Structure's genuinely strongest features, and it's a common reason teams stay on Structure even when they could otherwise simplify their toolset.

Foundation ships pre-defined rollups (count, sum of story points, earliest start, latest due, percent complete) that compute automatically from the hierarchy. There is no user-facing formula engine in the MVP — a formula editor is on the roadmap but not shipping today. Teams with sophisticated custom-rollup needs should evaluate Foundation carefully; teams with standard needs (dates + points + counts) will find the built-ins adequate.

What about cross-project scope?

All three tools can span multiple Jira projects, but they define scope in different idioms.

Jira Plans uses a saved-filter model. A plan is defined by one or more Jira filters (JQL) that include issues from whatever projects match. Adding a project means editing the filter. Plans are good at reflecting cross-project Jira state but are constrained by the hierarchy levels configured in Jira admin — if your projects don't share the same Initiative issue type, cross-project Plans get messy.

Tempo Structure is cross-project by default and doesn't care about issue types at all. You can drag an issue from Project A under an issue from Project B, and Structure stores the relationship in its own database. Generators can pull across projects with a JQL query. There's no concept of “the projects this Structure covers” — any issue from any project is fair game.

Foundation Lenses also treat cross-project scope as the default. A Lens is a view, not a project-scoped entity. Sync Agents pull issues via JQL regardless of project, and Flex Items can group cross-project children under a single Initiative. The mental model is closer to Structure than Plans here — hierarchy is authored in Foundation, not in Jira.

Which is most portable if you change your mind later?

Portability — the answer to “what happens to my hierarchy if I uninstall the app” — varies dramatically across the three.

Jira Plans is the most portable model by construction. All hierarchy lives as Jira issues with parent-child links. Uninstall Plans (or downgrade off Premium) and the issues remain — the hierarchy levels above Epic are still represented as real issues, and other tools that read Jira can still see them. The configured issue-type hierarchy itself reverts, but the data is intact.

Structure stores hierarchy in its own database. If you uninstall Structure, the Jira issues remain but the Structure-only relationships (position, folder composition, manual stacking) are gone unless exported first. Structure offers CSV export and has a mature backup/restore workflow, so this is manageable with planning — but you can't just walk away and have Jira look fine.

Foundation sits in between. Hierarchy is stored in Forge SQL attached to the Foundation installation. CSV export is supported, and issue-based nodes can be reconstructed from Jira issue links for anything that was modeled as a Jira link. Flex Items (non-issue nodes) have no Jira counterpart and require export if you migrate off. Because Foundation is Forge-native and uses Atlassian's own platform storage, data residency and backup follow Atlassian's own guarantees rather than a third-party vendor's.

Side-by-side: the three hierarchy models

Dimension	Jira Plans	Tempo Structure	Foundation Lenses
Maximum practical depth	1–2 levels above Epic (configured types)	Dozens of levels, unbounded in practice	Deep, but 1,000-issue cap per Lens (MVP)
Virtual vs issue-type	Issue-type only (every node is a Jira issue)	Both (issues + folders)	Both (issues + Flex Items)
Cross-project scope	Via saved filters	Native, no config needed	Native, via JQL Sync Agents
Rollups	Dates + story points (no custom formulas)	Full formula engine	Pre-defined only in MVP (no formulas yet)
Jira tier required	Premium or higher	Any Jira tier	Any Jira tier
Platform	Native (bundled with Jira)	Connect-based Marketplace app	Forge-native Marketplace app
Portability if removed	High — issues remain in Jira	Medium — export required for Structure-only data	Medium — CSV export; issue links preserved in Jira

How we evaluated these three models

We build Foundation, so treat this as a biased source and verify anything load-bearing. The comparison here is based on hands-on testing in March 2026 on identical three-project datasets (500–1,000 issues each) across all three tools. We built equivalent Initiative → Epic → Story hierarchies in each, ran cross-project rollup scenarios, exported and re-imported where supported, and benchmarked load time and edit latency. Vendor-published specs were used where hands-on testing wasn't feasible (e.g., Structure at 10,000+ issues, which exceeds the Foundation MVP scope).

What we did not test: Data Center editions of Structure (Foundation is Cloud-only, so the comparison stays Cloud-only), Structure.Gantt as a separate add-on (it's a different product), or Advanced Roadmaps on the legacy Server platform. For Gantt-specific comparisons see the companion guide; for product-level head-to-heads see Foundation vs Structure and Foundation vs Jira Plans.

Frequently asked questions

Do I need Jira Premium to get hierarchy above Epic?

Only if you use Jira's native Plans feature. Jira Premium is required to configure custom issue-type hierarchy levels (e.g., Initiative or Theme above Epic). Tempo Structure and Foundation Lenses both work on Jira Standard — they build their own hierarchy layer on top of any Jira tier, so you can have parent-of-Epic grouping without the Premium upgrade.

Which model gives the deepest hierarchy?

Tempo Structure, by a comfortable margin. Structure supports hierarchies that are dozens of levels deep via nested generators and manual composition, and it's been tuned for that scale since 2013. Foundation Lenses supports deep hierarchies too but caps at 1,000 issues per Lens in the MVP. Jira Plans is limited to the levels configured in the issue-type hierarchy (typically 1–2 levels above Epic), because every node must be a real Jira issue of a configured type.

Can I use more than one of these at the same time?

Yes. They don't conflict at the data layer. Jira Plans reads Jira issues; Structure and Foundation build their own hierarchy on top of the same issues. Some teams run Plans for premium-tier portfolio reporting and Structure or Foundation for day-to-day operations. Stacking is fine, but you'll maintain hierarchy in more than one place — most teams eventually consolidate on whichever model fits their workflow best.

How does portability compare if I change my mind later?

Jira Plans hierarchy lives in Jira issue-type relationships, so it moves with Jira. Structure stores hierarchy in its own Connect-backed database — portable between Structure views but not directly readable by other tools without export. Foundation stores hierarchy in Forge SQL attached to the app installation; data is exportable via CSV and the hierarchy can be reconstructed from Jira links for issue-based nodes. Flex Items (Foundation-only non-issue nodes) do not have a Jira counterpart, so they require an export if you migrate off.

Do all three support cross-project views?

All three support cross-project scope, but differently. Jira Plans lets you build a plan that spans multiple projects via issue filters. Structure builds cross-project hierarchies natively — you can drag any issue from any project into any position. Foundation Lenses are cross-project by design: a Lens is a view that can pull issues from any project via JQL-powered Sync Agents. The practical difference is in how you define scope — Plans uses saved filters, Structure uses manual composition or generators, Foundation uses JQL generators.

Which one handles rollups (sum of story points, etc.) best?

Structure has the most mature rollup system, with a formula engine that lets you define arbitrary calculated columns across hierarchy levels. Foundation rolls up dates and basic aggregates (count, sum of story points, earliest start, latest due) but does not ship a user-facing formula engine in the MVP. Jira Plans computes rollups for configured fields (dates, story points) automatically but does not support custom formulas. For complex custom rollups, Structure is the clear winner today.