How to Give JSM Customers Visibility into Linked Epics

No, not out of the box, and not partway either. Once a Jira Service Management request gets linked to an Epic in an engineering project, the customer's view of their own request never shows that Epic exists. It isn't a permissions setting you missed. The customer portal has no rendering for linked issues, child issues, or an Epic's progress bar, regardless of how open or locked-down the linked project is. Giving the customer project access would technically expose the Epic, but it also exposes every other issue in that project, which is usually the exact reason nobody wants to do it.

So the honest options are narrower than "flip a visibility toggle." Native JSM gives you two building blocks to work with: an automation rule that reacts when the linked Epic changes, and a small set of fields you can choose to show on the portal. Neither one, by default, turns "the Epic moved" into "the customer sees it." Here's what each piece actually does, and the point where most teams stop patching it themselves.

What the portal shows, and what it never will

A JSM request type controls exactly which fields a customer sees: summary, description, a status category, maybe a couple of custom fields you've explicitly added. What it does not have is a slot for "related issues." A responder on the Atlassian Community forums laid it out plainly: "The customer portal doesn't provide a method to show child issues or linked issues when viewing a Request." That's true whether the linked issue is an Epic, a Story, or a plain Task, and it's true whether it lives in the same project as the request or a different one entirely.

This is a portal limitation, not a permissions one. An admin with full access to both projects still can't make the portal render a linked Epic's status, because the request-detail view was built to show the request, not its neighbors. The workarounds people land on in that same thread are a custom field carrying a hand-maintained progress number, an automation rule that emails the customer separately, or a marketplace add-on built specifically to backfill this gap. None of them are "turn on visibility." All of them are "build a substitute."

The one native rule that gets close, and who it actually talks to

JSM does ship an automation recipe for exactly this connection, and it's worth understanding what it does before reaching for it. Atlassian's own automation documentation names it plainly: Automatically update agents about a linked work item's progress. Read that title again, because it's the whole story. The rule updates agents. It watches a linked issue for a status change and posts about it, but that post lands as an update inside the service project for the people working the request, not as a reply the customer sees on their portal page. Getting from "an agent got notified" to "the customer saw a status change" still takes a person converting that internal note into a public reply.

That's a real, working piece of machinery, and it's the reason support teams often believe they've already solved this. The link itself is native and accurate. Jira knows the request is tied to that Epic, no key-pasting or hand-matching involved. What it hands you is an internal heads-up, on time, tied to the right request. What it does not hand you is anything the requester can open and read.

A status the portal can't show

Brightfield Logistics moves freight on software from a route-planning SaaS vendor, and warehouse operations there answer to Lena Osei. She filed a request in August through the vendor's JSM portal, ticket SUP-4471. The afternoon batch of route re-optimizations had been failing silently for two weeks, and she needed it fixed before peak season started. The vendor's support lead triaged it, confirmed it was a known defect in the re-optimization engine, and linked SUP-4471 to Epic ENG-289, the team's existing rebuild of that engine.

Real progress followed. Two of five stories shipped in September, a third in October. None of it reached Lena. She checked the portal every couple of weeks, saw "In Progress" with no further detail, and eventually emailed support directly:

Lena, by email: Can someone tell me where SUP-4471 actually stands? The portal hasn't changed in a month and peak season starts in three weeks.

The support lead had been watching ENG-289's board the whole time. The information existed. It just never had a path onto the page Lena was looking at.

What has to keep being true for the custom-field version to work

The realistic native fix is a custom field on the request, something like "Engineering status," updated by hand or through an automation rule whenever the linked Epic's status changes, and shown to the customer as part of the request type's field configuration. Three things have to hold for that to keep working: someone remembers to keep the field current, the Epic doesn't get split or re-scoped in a way that breaks the automation's match, and you're doing this for a handful of linked Epics, not dozens running at once.

Past a few dozen customer-linked Epics, all three assumptions start failing at once. A field that depends on a human noticing a board change drifts stale within weeks. An Epic that gets split into two, the same problem covered in our guide on how to see who actually asked for a Jira Epic or Story, silently breaks whatever automation was watching the original Epic key. And a support team juggling this convention across many customers ends up doing, by hand, exactly what an internal agent-facing notification was supposed to save them from doing.

Where Modem picks it up

This is the point where teams stop trying to make the portal render something it was never built to show, and instead put something in place that reads the Epic directly and produces the customer-facing update itself. That's what Modem does here. It watches your connected Jira Service Management requests and your connected Jira projects side by side, follows the native link from a request to its Epic, and tracks that Epic's status as it moves, story by story. When it changes, Modem drafts the update in plain language, "3 of 5 stories done on the fix you reported," queued for a person to send through whichever channel the customer actually used. No portal permission changes, no engineering project access, and no custom field that goes stale the first time someone forgets to touch it. Modem is what we build, so read that comparison with the field-and-automation approach knowing where we sit; the underlying mechanics of matching a support request to the tracker issue that resolves it are covered in more depth in how to notify a JSM customer when linked engineering work is done.

Below a handful of linked Epics, the custom-field convention is genuinely enough, and setting up a whole second system to watch one or two Epics isn't worth it yet. Revisit it the moment a support lead is manually checking an engineering board more than once a week to answer the same question a customer keeps asking.

One customer-visible field, added today

Add one customer-visible field to your request type, "Engineering status" or similar, and wire the linked-work-item automation to write into it instead of only pinging agents. That's a same-day change, and it will beat "nothing" for as long as your linked-Epic count stays small. Once that field starts lagging behind what's actually true on the Epic, replace it with something that reads the Epic directly instead of waiting for a person to transcribe it.