How to link a Jira epic to the companies that requested it, not just people
Jira's Reporter field is built to answer "who filed this," and an epic only has one of them. It does not have a field for "which companies want this," and there's no setting that turns it on. If four different customers push for the same epic over six months, Jira will show you whichever single person happened to file the original ticket, and nothing else, unless you build the company tracking yourself.
That's the starting point. The rest of this guide covers how to build it: a custom field on the child issues underneath the epic, a JQL query that rolls those fields up by hand, and the specific point where a growing epic makes that rollup too slow to trust in a planning meeting.
What an epic actually tracks about who wants it
An epic is a container. It has its own Reporter, usually whoever created the epic, and it has child issues, stories and bugs, linked to it through the parent field. Atlassian's own documentation confirms this is the field JQL uses to search an epic's work items, with the older Epic Link field kept around only for backward compatibility. That's a real, working query, parent = PROJ-100 finds every story under epic PROJ-100.
What it doesn't do is aggregate anything about those children back up to the epic. If each story has a custom field for "requesting account," Jira has no built-in view that sums those values and shows "4 distinct accounts" on the epic itself. You get the list of children. Turning that into a company count is a query you run and read yourself, every time you want the answer.
This is also not the problem Jira Service Management's Organizations field solves, if you've run into that feature elsewhere. Organizations groups requesters inside a single service desk project, one ticket queue at a time. An engineering epic in Jira Software isn't a service desk request, and Organizations doesn't reach into it.
Building a rollup you can actually query
The fix is to put the account name where a query can reach it, not in prose. Two additions do this:
- A custom field on the story, not the epic. Add a short-text or single-select field,
Requesting Account, to your Story and Bug issue types. Fill it in at filing time, one value per child issue. - A label per account on issues that involve more than one. Labels are multi-value, so a story two companies both flagged in the same call can carry an
acct-label for each of them at once, which a single-select field can't hold.
With that in place, the rollup for an epic comes down to one saved filter, parent = PROJ-100 (or "Epic Link" = PROJ-100 on an older project), with the results grouped by the Requesting Account field, or a labels count if you're using the label convention. That filter is the current answer to "how many companies asked for this," as of the last time everyone filing a ticket remembered to fill in the field.
“we need SSO before rollout”
“any update on single sign-on?”
“SSO came up twice on this call”
Linear issue, quotes attached
insight report in NotionWhere the manual rollup stops holding up
The setup above works exactly as long as three things stay true, and each one degrades on its own schedule:
- Every filer fills in the field. A support engineer racing to close a call description skips it more often than a PM drafting a ticket at their desk does.
- Account names stay consistent. One account entered as its short name, its full legal name, and something in between is three different label values to a JQL query, even though it's one customer to everyone in the room.
- Nobody re-parents or splits the epic. The moment
PROJ-100gets split into "bulk import" and "field mapping," someone has to manually decide which account tags travel to which new epic, and the split usually happens faster than that decision gets made.
None of these breaks the system outright. They each just quietly lower the number the filter reports below the real one, and a low number reads as low demand instead of a missed field. By the time your rollup is quietly undercounting, nobody notices until someone happens to remember a missing company by name.
What Modem adds to the same epic
Modem is built for exactly the layer between a Jira epic and the companies behind it. Modem treats the company as the primary record, not a text field someone has to remember to fill in. It reads the calls, Slack threads, and support tickets your team already generates, matches the different ways "bulk import for onboarding" gets phrased across separate conversations, and rolls every one of those companies and the people at them up onto a single topic. Modem's Jira integration watches the connected projects and relates that same topic to the epic, so the topic shows the epic alongside a running count of the companies and the people who asked for it, rather than a Reporter field with one name on it. As the integration page puts it, feedback lands "grouped by what people are actually asking for and tied to the people and companies who raised it."
Modem is what we build and sell, which is a real bias here. Read the comparison with that on the table, and check it against whether your own team's account tagging is already slipping, not against how the pitch sounds. Below a handful of accounts per epic, the custom field and label convention above costs nothing and works fine. Past that, matching phrasings and normalizing account names by hand is the part that breaks first, which is also the piece Modem is doing under the hood. The wider gap between where customer context lives and where Jira implementation happens is described well in the Atlassian Community's own writeup on connecting feedback to Jira, whose blunt summary is that customer insights live in Slack, sales notes, and support tickets, while the implementation lives in Jira. Some tools close a narrower version of that gap already; the same article notes that inside Savio "you can see the total ARR tied to a specific Jira ticket," which is a company-level number Jira itself has no field for.
If this is the kind of gap you want surfaced automatically rather than reconstructed from memory, two related guides go deeper on adjacent pieces of it. How to see who actually asked for a Jira epic or story covers the single-reporter drift problem in more depth, and how to track feature requests in Intercom covers the same capture problem one channel upstream, before a request ever reaches Jira.
Start this week
Add a Requesting Account field to your Story and Bug issue types, and write one line in your ticket template telling filers to fill it in before they close the tab. Then run parent = YOUR-EPIC-KEY (swap in the actual key) on your oldest open epic and see how many of the child issues actually have that field populated. Whatever fraction is empty is roughly the size of the gap between what your epic's Reporter field shows and who's actually asked for it.