How to See All Jira Issues Across Projects in One View

Jira Cloud gives you four ways to view issues across multiple projects at once: (1) a JQL search without a project clause — free but flat; (2) a shared board driven by a cross-project filter — team-level and limited in scope; (3) Plans (Premium only) — wide but mostly read-only; and (4) a hierarchy app like Foundation's Lenses, Structure, or BigPicture — hierarchical, cross-project, and fully editable. Pick based on what you actually need to do with the view.

Why can't Jira show all issues across projects natively?

Jira was designed around the project as the unit of work. Every issue lives inside exactly one project; every board, backlog, and roadmap was originally scoped to exactly one project; and configuration — workflows, screens, permissions, custom fields — hangs off the project too. That per-project model is why your Scrum board shows ten sprints cleanly but can't tell you how your five teams' work rolls up into one release.

Atlassian has been walking that decision back for a decade. Boards can now be backed by multi-project filters. Plans (formerly Advanced Roadmaps) was added to Premium to span many projects. JQL has always been cross-project because it's a query language, not a view. But none of these fully replace the per-project navigation that's still the default everywhere in the Jira UI. The cross-project views exist; you just have to know where to look and which one fits your question.

Option 1 — How far can JQL take you?

JQL is the simplest cross-project answer. Open the Advanced Issue Search page, leave the project field empty, and run ORDER BY updated DESC. You get a flat list of every issue your account can see across the whole site, paginated, with column controls and CSV export. It's free, it respects Jira permissions, and it's always available.

Where JQL stops: no tree, no rollups, no grouping by parent, no swimlanes. A list of 8,000 issues sorted by update date is fine for an audit (“who closed a ticket in the last week?”) and useless for a portfolio review (“which epics are at risk across all our release trains?”). Inline editing on the results list covers assignee, status, priority, and labels — anything deeper requires opening each issue.

Best for: spot checks, audits, data exports, one-off “find me all the X across the site” questions. See our companion guide on cross-project JQL vs Sync Agents for a deeper comparison of JQL-as-a-view vs hierarchy apps.

Option 2 — When is a shared board enough?

A Jira board is driven by a saved filter. If the filter is project in (ABC, DEF, GHI), the board shows all three projects' issues on one screen — with swimlanes by assignee, epic, or label. That's enough for a single team running work across a few related projects, and it supports the same drag-between-columns workflow a single-project board does.

Where boards stop: the Kanban/Scrum format itself. A board shows issues in columns by workflow state, not in a tree by parent. Put 8,000 issues on a board and you get an unusable wall of cards. Boards also don't roll up story points or progress across parent-child relationships — for that you need a hierarchy engine underneath. See rolling up story points across projects for why this matters.

Best for: one team, 2–5 related projects, active sprint work, under ~500 in-flight issues.

Option 3 — What do Plans give you (and what's the catch)?

Plans (formerly Advanced Roadmaps) is Jira Premium's built-in cross-project planning surface. You point it at a set of issue sources (projects, boards, or filters — up to 100 per Plan) and get a Timeline view with Epics-and-above hierarchy, capacity planning, and scheduled dependencies. It's the only native Atlassian answer for a portfolio-level cross-project view.

The catches: Plans requires the Jira Premium tier, which is a significant per-user price jump from Standard. Plans is mostly read-only for scheduling workflows — you edit dates in a right-hand side panel, not by dragging on the timeline, and no dependency arrows are drawn between bars. Plans also treats the Epic as the default bottom of the hierarchy, so if you want to see Stories and Tasks rolled up under Epics in a single view, it's less helpful than it sounds.

Best for: program managers who already have Jira Premium, need a portfolio-wide Epic-level roadmap, and don't need to bulk-edit inside the view.

Option 4 — Why hierarchy apps change the view entirely?

Marketplace hierarchy apps — Tempo's Structure, Appfire's BigPicture, and Foundation — treat cross-project hierarchy as a first-class primitive. A Foundation Lens is a saved view that can pull in issues from any project on the site, arrange them in an arbitrary tree (not limited to Jira's built-in Epic/Story levels), and support full inline editing on every field. Structure and BigPicture do the same thing with their own idioms.

The difference from Plans is that these apps were built hierarchy-first, not timeline-first. You get group-by-anything, rollup math on story points and progress, custom hierarchy levels (initiative-under-epic-under-story-under-subtask, or whatever your org uses), and bulk edit across projects. Honest caveat for Foundation specifically: the MVP caps a single Lens at 1,000 issues. For portfolios above ~10,000 issues in one view today, Structure and BigPicture are the safer bet. Foundation's roadmap includes higher limits.

Which option fits which team size and org shape?

Option	Scope	Hierarchy	Cross-project	Inline edit	License cost	Best for
JQL search	Whole site	Flat list only	Yes	Basic fields only	Included with Jira	Audits, spot checks, exports
Shared board	Up to ~5 projects	Columns by state, not tree	Via JQL filter	Yes (card fields)	Included with Jira	One team across 2–5 projects
Plans (Premium)	Up to 100 sources/Plan	Epic-and-above only	Yes	Side panel only, not on bars	Requires Jira Premium	Portfolio roadmap, program managers
Foundation Lens	Whole site (1,000/Lens MVP)	Arbitrary custom tree	Yes (first-class)	Full, all fields	Per-user, below Premium delta	Cross-project PPM, inline editing
Structure / BigPicture	10,000–50,000+ issues	Arbitrary custom tree	Yes (first-class)	Full, all fields	Per-user, enterprise tier	Large portfolios, mature PPM

Pattern: under ~500 issues, JQL or a shared board is usually enough. 500–10,000 issues across more than a handful of projects and you'll outgrow both quickly — that's where Plans (if Premium fits), Foundation, Structure, or BigPicture pay off. Above 10,000 issues in one view today, Structure and BigPicture are the established answers; Foundation gets you there for smaller portfolios with a cleaner UX and a Forge-native install (no data egress, Cloud Fortified).

How do you evaluate on a real dataset?

Vendor demos use curated data that makes every tool look fast. Before picking between Plans and a Marketplace app, run the same exercise on your actual issues:

Pick 3 representative projects — one small (~100 issues), one medium (~1,000), one large (~5,000+).
Build the same view in each candidate tool — same filter, same grouping, same columns.
Time the full render from click-to-open to scrollable. Anything over 3 seconds on 1,000 issues is a red flag.
Try an inline edit — change a status, a story point estimate, an assignee. Confirm it writes back to Jira within seconds.
Check permission honesty — impersonate or sign in as a user who shouldn't see a specific project. The cross-project view must exclude those issues automatically.

All three Marketplace apps (Structure, BigPicture, Foundation) offer free trials. Jira Premium for Plans is billable during trial, so coordinate with the Atlassian admin before turning it on site-wide.

Where Foundation fits

Foundation was built for the middle of the range: teams that have outgrown a shared board, don't need (or don't want to pay for) Jira Premium just for Plans, and want a proper hierarchy view without committing to an enterprise-tier PPM tool. A Foundation Lens spans every project on the site, supports full inline editing on any Jira field, and respects Jira's BROWSE permission at the issue level. Because Foundation is Forge-native, there's no data egress, no separate vendor security review, and installation takes about sixty seconds.

For the broader context of why cross-project visibility matters and where it sits in a PPM toolchain, see the pillar guide on cross-project Jira reporting.

Frequently asked questions

Can I see all Jira issues across every project in one place without a paid app?

Yes, to a point. A JQL search with no project clause (for example, `ORDER BY updated DESC`) returns every issue your account has BROWSE permission on across every project on the site. You get a flat list with sorting, filtering, and export, but no hierarchy, no rollups, and no grouping by parent. That works for audits and spot checks; it does not work for portfolio reporting.

Does the cross-project view respect Jira permissions?

Every option here honors Jira's project-level BROWSE permission. If you cannot see a project in Jira, you cannot see its issues in a JQL search, a Plan, a Structure, a BigPicture box, or a Foundation Lens. Hierarchy apps add their own access control on top — for example, a Foundation Lens can be shared with view, edit, or control permissions independent of Jira project roles — but they never bypass Jira's own permissions.

How many projects can one Jira Plan include?

Atlassian documents Plans as supporting up to 100 issue sources per Plan, where a source is typically a project, board, or filter. In practice most Premium customers run Plans against 5 to 30 sources. If you need to span more than 100 projects in one view, you either split into multiple Plans or use a Marketplace hierarchy app like Structure, BigPicture, or Foundation, which treat cross-project scope as a first-class primitive.

Why does my Jira board only show issues from one project even though I added more?

Boards are driven by a saved filter (JQL). If your board's filter has `project = ABC` hardcoded, adding a second project in settings does not change the filter. Edit the filter to something like `project in (ABC, DEF)` — or remove the project clause entirely and use a `component` or `label` filter instead — and the board will draw from both projects.

We have 15,000 issues across 40 projects. What is the realistic option?

At that scale, Jira Plans will surface the issues but lock you out of inline editing and deep hierarchy. Foundation's MVP caps a single Lens at 1,000 issues, so a 15,000-issue portfolio would need multiple Lenses or a different tool today. Structure and BigPicture both handle 10,000 to 50,000+ issues in one structure and are the safer bet for portfolios that size right now. Foundation is catching up on scale; check the product roadmap before committing if you need more than 1,000 issues per view in 2026.

Can I edit issues directly in a cross-project view, or only read?

JQL search results in Jira Cloud support some inline editing (assignee, status, priority, labels) directly on the results list. Boards support drag-between-columns and inline edits on card fields. Plans is mostly read-only for scheduling workflows — you edit in the side panel, not on the timeline. Structure, BigPicture, and Foundation all support full inline editing across every issue in the view, including cross-project.