Cross-Project Jira Reporting: How to See Your Whole Portfolio in One View

Jira's default view is project-siloed — every board, backlog, and report scopes to a single project. Cross-project reporting, where you pull issues from 10+ projects into one view with roll-ups, dependencies, and executive summaries, requires either JQL engineering, Jira Premium's Plans feature, or a Marketplace app like Foundation, Structure, or BigPicture. Here is how each approach works, what it costs, and when to use which.

Why is cross-project reporting hard in Jira by default?

Jira was designed around the project as the primary unit of work and permission. Every board, sprint, backlog, roadmap, and built-in report is scoped to exactly one project. If you manage three engineering squads in three projects, Jira gives you three separate sprint reports and no native way to combine them. The project boundary is also a permission boundary — users get role-based permissions per project, which means a cross-project view must enforce a per-issue BROWSE check, not a single project-level check.

The hierarchy limit compounds the problem. Jira's standard hierarchy tops out at Epic, with Stories and Subtasks below. There is no native “Initiative” or “Theme” level above Epic unless you are on Jira Premium with the Plans feature enabled. Even then, custom hierarchy levels are limited and do not roll up cleanly across projects that use different issue-type schemes. The result: program managers running 10 projects have no native way to ask “what is the status of the Q3 commitments across all teams?” without building something custom.

What is a cross-project report, exactly?

A cross-project report is any view that combines issues from two or more Jira projects into a single artifact — a list, a hierarchy, a Gantt chart, a dashboard, or an export. The defining feature is that the view crosses the project boundary without duplicating data or losing permission checks. Concrete examples teams ask for every week: “all overdue epics across our eight product projects,” “a story-point burndown combining the dev and design squads for this sprint,” “a dependency map for Q3 commitments that spans engineering, QA, and infrastructure projects,” or “one Gantt chart for the 2026 roadmap across all teams, roll-up to Initiative level.”

What distinguishes a real cross-project report from a glorified JQL filter is three things. First, hierarchy: children live under parents, and parents can live under synthetic headers like “Q3 Initiatives” that are not Jira issues at all. Second, roll-ups: story-point totals, percent-complete, start and end dates, budget, and RAG status computed from children and displayed on parents. Third, freshness: the report reflects the current state of Jira within seconds of a change, not whenever someone remembers to re-run the query.

How to build cross-project JQL filters

JQL (Jira Query Language) is free, included in every Jira edition, and surprisingly capable for flat cross-project lists. The core pattern is project in (ENG, MKT, DES) to scope to multiple projects, combined with any other clauses you want. To filter to all overdue epics across three projects: project in (ENG, MKT, DES) AND issuetype = Epic AND duedate < now() AND status != Done. Save the filter, share it, subscribe to its email delivery, or embed it in Confluence. The advanced JQL reference lists every available field and operator.

The limits show up fast. JQL returns a flat list, not a tree — you cannot group by Epic with Story children indented below. Custom fields that exist in one project but not another silently exclude half your data. Sprint reports only work within a single board. Linked-issue traversal in JQL (issueFunction in linkedIssuesOf) is a ScriptRunner extension, not native. Permission filtering is correct but per-user results differ, which makes “share this report” an inconsistent experience. For lists under 100 issues with no hierarchy requirement, JQL is enough; past that, the next tier is Jira Plans or a Marketplace app.

How to use Jira Plans for cross-project reporting

Jira Plans (the feature formerly called Advanced Roadmaps) is bundled with Jira Premium and Enterprise at $15.25/user/month and above. A Plan pulls issues from any number of boards, filters, or projects into a single hierarchical roadmap — the closest native cross-project experience Atlassian offers. Plans support custom hierarchy levels above Epic (Initiative, Theme), Gantt-style timeline rendering, sprint-level capacity planning, and scheduling across teams. For a single program manager inside a Jira Premium tenant, Plans can cover a lot of ground without a Marketplace app.

Plans' real limits are rigidity and breadth. The hierarchy configuration is set at the Jira admin level and applies to every Plan uniformly — you cannot have one Plan that uses Initiative → Epic → Story and another that uses Theme → Objective → Key Result. Inline editing is limited compared to a full grid (try updating 50 issue assignees at once in Plans). Reporting visuals are roadmap-first; there is no spreadsheet-style grid with 30+ rows visible. Sharing with non-Jira stakeholders requires screenshots or CSV export. And the price gate — $15.25/user/month, across every Jira user in your tenant — is a blocker for teams that do not otherwise need Premium features.

How Marketplace apps solve the cross-project reporting problem

Three apps dominate the Atlassian Marketplace PPM category, and each takes a slightly different architectural approach. Structure by Tempo (14,071 installs) was the first and remains the incumbent; it ships JQL-based generators that auto-populate hierarchies and an Expr formula engine with 100+ functions for custom roll-ups. BigPicture by Appfire organizes cross-project data into modules (Scope, Gantt, Resources, Risks, Objectives) each with its own opinionated UI. Foundation is the newest entrant, Forge-native, and uses Sync Agents — JQL Insert and Child Extend — inside Lenses that function as cross-project portfolio workspaces.

The honest trade-off matrix: Structure wins on formula depth and install-base maturity but runs on the legacy Connect platform and has raised prices three times in 18 months. BigPicture wins on breadth — resource histograms, risk modules, objective tracking — but its modular UI has a steeper learning curve and also runs on Connect. Foundation wins on modern architecture (Forge-native, zero data egress, event-driven freshness), price, and simplicity. Foundation trades off formula-engine parity (shipping Q1 2027) and raw scale (MVP is tuned for 1,000-issue Lenses). For a full head-to-head see Foundation vs Structure, Foundation vs BigPicture, and Foundation vs Jira Plans.

How to build executive-ready cross-project reports

An executive audience wants portfolio state in under 30 seconds of scanning. The ingredients that consistently land: a summary hierarchy that collapses the portfolio to 10–25 top-level rows (Initiatives or Programs, not individual Stories); a RAG status column (Red/Amber/Green) driven by rules — overdue, over-budget, or off-track triggers Amber or Red; roll-up percent-complete and story-point totals computed from children to parent; a Gantt view that shows the same data on a timeline with dependency arrows; and a one-page PDF or image export for the next steering-committee deck.

The mechanical advice: put the summary hierarchy at the top, order children by priority or date within each parent, use conditional formatting so Red cells are visible from across the room, and keep column count below eight on the summary view (more columns are fine on a drill-down view). Flex Items in Foundation let you create non-Jira organizational headers like “Q3 Commitments” that group children without polluting Jira with fake issues. Structure has an equivalent called folders, BigPicture has similar scope boxes. The point is the same across all three tools: executives are not reading your JQL, they are reading your roll-ups.

How to keep cross-project reports fresh without manual refresh

Three freshness architectures exist, and they matter for both UX and cost. First, polling: the app asks Jira for changes on a timer (every 5 minutes, say). This is how Connect apps historically worked. Every poll costs Jira API rate-limit points against a shared pool. Atlassian's Tier 1 rate limits cap the global pool at 65,000 points/hour across every app installation, with each JQL search of 100 results costing 101 points. Polling-heavy apps exhaust this shared pool during spikes and degrade for every other app on the tenant.

Second, scheduled exports: Jira filter subscriptions, BigPicture and Structure saved reports, and email-delivered CSVs. These are cheap but stale — your 9am report reflects whatever Jira looked like at 8:55am. Third, event-driven caching via Forge: the app subscribes to Jira product events (avi:jira:updated:issue, avi:jira:created:issue) which fire for free on every change with no API-point cost. Foundation is built around this model: when a Jira issue updates, the event handler fires within seconds and updates Foundation's local cache, then pushes a Forge Realtime message to any open Lens so the UI refreshes automatically. The user never clicks a refresh button.

If you are evaluating a Marketplace app purely on cost-per-tenant, the Connect-vs-Forge distinction matters. Connect apps pay Jira API points for freshness. Forge apps pay zero points for event-driven freshness and only pay when doing writes or explicit JQL runs.

How to handle cross-project permissions correctly

The permission model for a cross-project report is deceptively simple: each user should see exactly the issues they have Jira BROWSE permission on, and nothing more. In practice every Marketplace app gets this slightly wrong in at least one edge case, and custom JQL reports lose the guarantee the moment you export to a shared Confluence page or email. The right architecture is fail-closed by default: if the permission check fails for any reason, hide the issue rather than risk leaking it.

Foundation's implementation: on every Lens read, the backend issues a bulk permission check for every issue key in the Lens against Jira's BROWSE permission, using a batched JQL query for efficiency. Results are cached in Forge KVS for 15 minutes per user. If Jira is unreachable the cache still serves, but any new additions without a positive permission confirmation are hidden. Flex Items (non-Jira organizational headers) use Foundation's own ACL stored in Forge SQL — owner, view, edit, edit_generators, control levels with cascading inheritance from parent to children. Structure and BigPicture use equivalent per-issue Jira BROWSE enforcement with app-level ACLs layered on top. The consistent rule across all three:hidden parent means hidden children, regardless of whether the user has direct permission on a child issue.

What cross-project reports matter for which audience?

Different roles ask different questions of the same underlying data, and the effective report shape changes per persona. The individual engineer cares about dependency clarity — “what is blocking my story and who owns it?” A good answer is a dependency view that spans projects and shows the blocker issue regardless of project. The engineering manager asks about velocity roll-up — “are we on pace for this sprint across my three squads?” A good answer is a grouped grid with story-point totals per squad and RAG status on the aggregate.

The program manager asks about critical path — “which Q3 commitments are at risk and what is the cascade impact?” A good answer is a Gantt view with dependencies and critical-path highlighting across all projects in the program. The executive asks about portfolio health — “are we going to ship the 2026 plan?” A good answer is a one-page portfolio summary with 10–25 top-level initiatives, RAG status, percent-complete, and a drill-down path to detail for the conversations that follow. Foundation Lenses were designed around this last persona first — the portfolio summary is the default shape — with drill-down views for every audience below.

Cross-project reporting: approach comparison

Approach	Cost	Hierarchy	Roll-ups	Freshness	Best for
JQL filters	Free	Flat list	None	On-demand	Quick lists, < 100 issues
Jira Plans (Premium)	$15.25/user/mo+	Global config only	Basic	Near real-time	Single-program roadmaps
Structure by Tempo	Paid, per user	Unlimited, generators	Expr formulas (100+ fns)	Polling + webhooks	Formula-heavy reporting, 10K+ items
BigPicture by Appfire	Paid, per user	Unlimited, modules	Module-level	Polling	Resource histograms, risks
Foundation	Free 1–10, paid above	Unlimited, Sync Agents + Flex Items	Built-in + Q1 2027 formula engine	Event-driven (zero API cost)	Cross-project portfolios, Forge-native tenants

How we built this guide

We build Foundation, so treat this as a biased source on Foundation itself and independently verify the Structure, BigPicture, and Jira Plans claims we make. That said, the framing is based on direct hands-on testing of all four approaches on the same 500-issue portfolio across three Jira projects during March–April 2026. We wrote the same “overdue Q3 epics” cross-project report in raw JQL, in Jira Plans, in Structure with Expr, in BigPicture with a Scope module, and in Foundation with a JQL Insert Sync Agent. We measured time-to-report, rows-to-answer, freshness lag, and permission enforcement edge cases for each.

What this guide does not cover: EazyBI, Rich Filters, Custom Charts, and other reporting-specific Marketplace apps. Those compete in a narrower lane (dashboard/chart tooling) and are often deployed alongside a PPM app rather than instead of one. We also did not test Jira Data Center — every tool and pattern here applies to Jira Cloud, which is where Atlassian is steering new deployments.

Frequently asked questions

Can I do cross-project Jira reporting without paying for Premium?

Yes. Jira Standard includes advanced JQL search, which lets you query across any projects you have BROWSE permission on. A JQL filter like `project in (ENG, MKT, DES) AND status != Done` returns issues from three projects in one result set, and you can save the filter and subscribe to it. The limits are structural, not licensing: you get a flat list, not a hierarchy, and you cannot roll up story points or dates from children to parents without either Jira Premium's Plans feature or a Marketplace app like Foundation, Structure, or BigPicture.

Does Structure sync in real time across projects?

Structure is a Connect app, so it historically relies on polling Jira for changes. Tempo has added webhook-driven refreshes, but Connect apps cannot subscribe to the free `avi:jira:*` product events Forge exposes. Every poll or webhook fetch costs Jira API points against the shared rate-limit pool. Foundation is Forge-native and subscribes to Jira product events directly — updates flow into the cross-project cache within seconds without consuming any API points. For a deeper comparison see our /compare/vs/structure page.

How does Foundation avoid rate-limit issues on large cross-project reports?

Foundation caches issue data locally in Forge SQL and refreshes it through free product events (`avi:jira:updated:issue` and siblings). Reading a 1,000-issue Lens pulls zero points from Atlassian's 65,000-points-per-hour Tier 1 global pool — the read hits our cache, not Jira. Only writes and occasional JQL-driven Sync Agent runs consume points. Foundation has also been granted Tier 2 rate limits, which give per-tenant budgets of 100,000–500,000 points/hour on top of the event-driven architecture.

What is the biggest cross-project portfolio view I can build?

Foundation's MVP supports Lenses of up to 1,000 issues across any number of projects. Structure and BigPicture both support larger plans — Structure is comfortable past 10,000 items, BigPicture is similar. Jira Plans can hold thousands of issues but hides ones outside your active scope. For reports of 5,000+ items with resource histograms you are in BigPicture/Structure territory today. For typical program portfolios (5–30 projects, 200–1,500 issues) Foundation is sized correctly.

Can I export cross-project reports to CSV or Excel?

Yes, in every serious PPM app. Foundation ships a CSV export that respects the current sort, grouping, and visible columns so the export matches what you see on screen. Structure and BigPicture have equivalent CSV export. Jira itself exports JQL results to CSV via the issue navigator. For formatted Excel with conditional styling, most teams export CSV and apply a saved template in Excel/Google Sheets — native .xlsx export is roadmap for Foundation.

What about Confluence embeds or scheduled reports?

Confluence can embed a Jira filter as a table macro, which covers basic cross-project lists directly from JQL. For hierarchy-aware embeds (a Foundation Lens inside a Confluence page), that integration is on the roadmap. For scheduled email reports, Jira's filter subscription emails you the filter results on a cron schedule, and several Marketplace apps (EazyBI, Rich Filters, Foundation's upcoming scheduled-export feature) add scheduled delivery for formatted reports.

How do I report on custom fields consistently across projects?

The pain: different projects often use different custom-field IDs for the same business concept (Team, Squad, Budget). JQL can reference a custom field by name or `cf[10001]` ID, but if "Team" exists in only two of your five projects, the filter silently excludes the three without it. Foundation's column picker detects custom fields across the projects in a Lens and surfaces them as a single column when the field IDs match, and flags field-name collisions. Structure and BigPicture handle this similarly — they abstract custom fields into formula variables so your reports work even when a field is missing in a given project.

How do I handle cross-project permissions without leaking issues?

Every serious cross-project report must enforce Jira's permission model — a user should only see issues they have BROWSE permission on. Foundation checks Jira BROWSE permission per issue on every Lens read and caches the result for 15 minutes (KVS-backed). If Jira is unreachable, Foundation fails closed by default — hiding cached issues rather than risk leaking them. Structure and BigPicture enforce the same model. Custom-built JQL reports rely on Jira enforcing permissions natively, which is reliable for JQL but loses the enforcement guarantee if you export to a shared Confluence page.