Sharing Jira Reports with Non-Jira Stakeholders

Your VP wants you to send the portfolio roadmap to the board. The board has no Jira licenses. Five options, ranked by fidelity: (1) a Confluence page embed with the Jira Issues macro (still usually requires a license), (2) PDF or image export (loses interactivity), (3) CSV export (loses everything but raw data), (4) Jira's public-anonymous issue view (works only in narrow cases), and (5) a third-party public-link app (fastest, with security tradeoffs). Each loses signals differently — pick based on who's reading.

Who actually needs Jira access — and who doesn't?

Sort stakeholders into two buckets. Internal viewers on corporate SSO can usually be provisioned into Jira as licensed users without procurement friction — they open the real dashboard and drop out of your sharing pipeline. True externals (clients, board members, auditors, press) will never have Jira accounts on your site; everything below is for them. The most common mistake is conflating the two.

Option 1 — Confluence page embed

The Jira Issues macro in Confluence is the highest-fidelity option. Paste a JQL query into a Confluence page, and the macro renders a live table that updates whenever the underlying issues change.

The catch: the reader still usually needs a licensed Jira account with Browse Projects on every referenced project — Confluence defers to Jira's permissions, it doesn't proxy them away. A true external sees a “no permission” placeholder. What you lose: custom Gantt views, conditional formatting, and cross-project hierarchy rollups. A Foundation Lens with a 3-level hierarchy renders as a flat leaf list.

Option 2 — PDF or image export (what Foundation/Structure/BigPicture support)

A static PDF or PNG is the most universally-compatible format. Anyone with an email client can open it, and you get pixel-perfect control over what's shared — no permission surprises at the reader's end.

Foundation supports image (PNG) and PDF export at MVP, driven from the current view. Structure.Gantt and BigPicture both offer PDF export with print-tuned pagination; Jira's native Timeline has a basic PDF export usually cropped for wide plans.

What you lose: interactivity — no sorting, filtering, or drill-down. PDFs also embed metadata (author, file path, edit history), so use “Export as PDF” rather than “Print to PDF” and scrub metadata for sensitive audiences.

Option 3 — CSV export for analysts

When the reader is an analyst — finance, risk, a consulting firm — they don't want a pretty chart; they want rows they can run through Excel or Tableau. Jira exports via the advanced JQL page; Structure, BigPicture, and Foundation all export their hierarchy as a CSV with indent columns preserved.

What you lose: visualization, dependencies, and rich-text fidelity (ADF flattens to markdown-ish strings). CSVs also leak more than intended because they're the widest format — comments, watcher emails, forgotten custom fields. Always export from a pre-filtered view (Foundation Views, Structure column configurations), not a raw JQL dump.

Option 4 — Jira's public issue view — where it works and where it doesn't

Jira Cloud supports anonymous public access when a site admin grants “Browse Projects” to the “Anyone” group via the global permissions system. This is how open-source projects (Apache, Spring) publish their bug trackers. It almost never applies on enterprise Jira sites — admins don't enable it, and turning it on is usually a security incident waiting to happen. The permission also operates at the project level, so you cannot share a single issue publicly while keeping the rest of the project private.

Option 5 — Public-link apps and security tradeoffs

A handful of Marketplace apps publish read-only Jira data outside the Jira auth boundary. Bigbrassband External Share for Jira is the reference example — it generates a public URL scoped to a specific JQL query or issue set, with no Jira account required. Similar apps exist for dashboards and roadmaps.

What you gain: live data for true externals, no per-reader licensing cost, and a URL you can drop into an email. For agencies and vendors showing clients their own tickets, this is often the only workable option.

Security tradeoffs: every public link is a potential data leak. Require password protection, expiration, and access logs at minimum, and check the vendor's trust posture (SOC 2, data residency, breach notification) before adopting. Pair any public-link sharing with access logging and a data-classification review.

Foundation's position: public-link sharing is not in the MVP. Foundation is Forge-native with zero data egress — processing stays inside Atlassian's Cloud Fortified boundary. PDF and image export cover most snapshot needs today; see Foundation security for the platform context.

How do you pick based on stakeholder type?

The matrix below maps stakeholder type to the option that usually fits, with signal loss flagged.

Stakeholder type	Recommended option	What's lost
Client (agency/vendor relationship)	Option 5 (public-link app, password-protected) or Option 2 (PDF weekly)	Live updates if you go PDF; data-boundary control if you go public-link
Executive / board member	Option 2 (PDF or image in the board deck)	Interactivity and drill-down. Acceptable for a quarterly review.
Auditor (SOX, SOC 2, ISO)	Option 3 (CSV export of the audit period) + Option 2 as evidence attachment	Visualization; auditors want the raw rows. Keep an audit trail of what was exported and when.
Press / analyst (public release)	Option 4 (Jira public view) if you're truly open, else Option 2 (curated PDF)	Real-time updates and any commentary fields. Always curate what's exposed.
Internal employee on corporate SSO	Grant them Jira access — don't export	Nothing. They get the real source.

Two rules apply to every row. Classify before you share: does this contain PII, financials, or unreleased roadmap? Log access where possible: if the app supports link-level access logs, enable them. For recurring exports, build a saved View once and export from that View every time instead of reconstructing the filter. See how to see all Jira issues across projects for assembling the data set, and rolling up story points for the number the board usually asks for.

Where Foundation fits

Foundation gives you a single Lens across multiple Jira projects, with a View system for building a “board-safe” column set (title, owner, status, target date) separately from your engineering-detail View. Switch to the board-safe View and export as PDF or image. Public-link sharing is on the roadmap; for now, Forge-native security means nothing leaves the Atlassian boundary during the export. Back up to the pillar at Cross-Project Jira Reporting.

Frequently asked questions

Do executives need a Jira license just to look at a report?

In most Jira Cloud configurations, yes. The Confluence Jira Issues macro, the Jira Cloud mobile app, and direct issue links all require the viewer to be a licensed Jira user with Browse Projects permission on the source project. The only no-license options are (1) a static export (PDF, image, or CSV) sent to them, (2) Jira’s public-anonymous issue-view feature if the project allows it, or (3) a third-party public-link sharing app that publishes a read-only view outside the Jira auth boundary.

Can I share a Jira dashboard with someone outside my org?

Not directly. Jira dashboards respect project permissions — a true external (no licensed Jira user account on your site) cannot open a dashboard URL even if you set the dashboard itself to "public." You need to either add them as a licensed user (which costs money and usually fails procurement), export the dashboard as a PDF/image, or use a Marketplace app that publishes a public read-only view with its own link.

What about SSO — are internal employees "external" if they aren’t in Jira?

Technically yes, but practically no. If your Jira site uses Atlassian Access with SSO and an employee already has corporate credentials, adding them as a Jira user is usually a provisioning step — not a procurement one. For internal audiences, the cleanest answer is often to grant them the free Jira role (read-only on some plans) and let them view the real source. The messier options (export, public link) are for true externals like clients, auditors, and press.

Does Foundation support public-link sharing today?

Not in the MVP. Foundation ships image (PNG) and PDF export at launch, which covers the "send the board a snapshot" case. Public-link sharing — where a stakeholder with no Atlassian account can open a live, read-only Foundation Lens — is on the post-MVP roadmap. If you need public-link sharing today, Bigbrassband External Share for Jira and a couple of other Marketplace apps offer it, with the security tradeoffs discussed above.

How do I prevent a shared report from leaking sensitive fields?

Before any export, decide what fields are board-appropriate and strip the rest. A common mistake is exporting a full Jira issue dump — including assignee emails, comments, and internal labels — when the board only needs title, status, and target date. Foundation’s view system lets you build a "board-safe" view with just the columns you want shared, then export from that view. For CSV exports going to analysts, spot-check the file in a text editor before sending; PII and internal URLs routinely slip through.

Should I log who accessed a public-link report?

Yes — and more importantly, classify the data before you publish the link. Any Marketplace app that offers public-link sharing should give you access logs (who hit the link, when, from what IP). Pair that with a data-classification review: if the report contains PII, financials, or unreleased product info, the link should be password-protected at minimum and probably not used at all. Treat public links like you’d treat a sales quote — trackable, expiring, revocable.