How to build a client-facing Jira dashboard in Confluence

If you already live in Confluence, you're sitting on a decent client-reporting tool and you might not know it. Confluence can pull live Jira data into a page, so instead of exporting a stale PDF every week, you can maintain a single dashboard that's current whenever someone opens it. It's one of several honest options covered in gJira for agencies: the reporting problem nobody warns you about.

There's one catch that decides whether this is the right route for you, and I'll get to it — but it's a licensing catch, not a technical one, so let's build the thing first and then be honest about who it's for.

What you're building

A single Confluence page with three parts: a short written summary at the top (the interpretation — is it on track, what changed), one or two embedded live Jira lists in the middle (what's done, what's in progress), and optionally a roadmap or timeline. The written part you control; the Jira parts update themselves.

Step 1: Create the page and set the permissions

Create a new page in the space you'll share. Before anything else, decide where it lives, because Confluence permissions are inherited from the space. If your working space contains internal notes you don't want a client seeing, either put this page in a dedicated client-facing space with its own restrictions, or apply page-level restrictions so only the right people can open it. Get this right first — it's much easier than discovering later that a client can navigate to your internal retro notes.

Step 2: Add the written summary

At the top, write two or three sentences in plain language: the overall status, what moved this period, and anything the reader should know. This is the part a stakeholder actually reads. Resist the urge to skip it and let the embedded data "speak for itself" — raw Jira data doesn't speak, it mumbles. (For the specific questions that summary needs to answer, see gwhat stakeholders actually want to know about a project.)

Step 3: Embed a live Jira issue list

Type / to open the macro menu and choose the Jira Issues macro (you may see it labelled Jira Legacy depending on your version). Paste a JQL query or pick a saved filter. Useful ones:

• Recently completed: project = ABC AND status changed to Done AFTER -7d
• In progress: project = ABC AND status = "In Progress" ORDER BY priority DESC

Choose only the columns a non-technical reader needs — summary and status, maybe assignee. Hide the ticket keys and story points; they're noise to a client. Add a second macro for a second list if you want a "done / doing" split.

Step 4: Add a roadmap or timeline (optional)

If your reader cares about when, add a Jira Roadmap macro or embed a timeline view. Keep it high-level — epics or milestones, not individual tickets. A client wants the shape of the plan, not its atoms.

Step 5: Share it

Send the page link. If your client has Confluence access and permission to the space, they open it and see the current state. Done — and genuinely better than a weekly PDF, because there's no weekly and no PDF.

The catch, stated plainly

This works beautifully when your client already has Confluence access. The moment they don't, you're back to the original problem wearing a new hat: to see the page, they need a Confluence seat, which costs money per person and requires them to log into a tool they don't otherwise use. You haven't escaped the licensing wall — you've moved it from Jira to Confluence.

There's a public-publishing option (Confluence can publish pages to the web), and some teams use it. But public means genuinely public — anyone with the link, and anything a search engine indexes. For an open roadmap you want the world to see, fine. For one client's confidential project, it's an exposure, not a solution.

So the honest test: if you and your client both live in Confluence already, this is one of the best free options available, and you should build it. If they don't, this route quietly costs a seat per client, and you'd be fairer to yourself evaluating a tool built to share externally without a login — whether that's a full-access app like gExternal Share for Jira, or a status-page app for readers who shouldn't see a board at all. (Our gcomplete guide to sharing Jira status without a license walks through the full field, Confluence included, side by side.)

But if the Confluence access is already there? Spend the afternoon. It's a real upgrade over the export-and-email treadmill.

---

I'm Andrey. I build small, focused apps for Jira at gGuenov Labs. This tutorial uses only native Jira and Confluence features.