How to see who actually asked for a Jira epic or story
Start with the Reporter field, and run a JQL search for what it used to say, not just what it says now. Jira tracks changes to Reporter over time, so a query like reporter WAS "dcho" finds every issue where that person was ever listed, even if someone has since reassigned it to themselves or a generic intake account. That gets you the person who filed the ticket in Jira. It does not necessarily get you the customer who asked for it, and after a few months and one epic split, those are often two different people.
That gap is the real problem behind this question. Jira has one field for "who reported this," and it was built for bug reports filed by the person who hit the bug, not for a PM typing up a request that arrived somewhere else entirely. Here's what Jira keeps, where that trail runs out, and what to do about it.
What Jira keeps, and how to search it
Every Jira issue, epic or story, has a Reporter field. Atlassian's own JQL reference is explicit that this is not the same thing as who created the ticket: "This may be the same as the creator, but can be distinct." Reporter also supports the WAS, WAS IN, WAS NOT, and CHANGED operators, which is the part most people miss. Practically, that means:
reporter WAS "devon"— every issue Devon was ever listed as reporter on, even if it's since changed.reporter CHANGED— every issue where the reporter field has been edited at least once, which is your list of tickets where the original filer might not be who's showing now.reporter CHANGED AFTER "2026-01-01"— narrow that to a specific window, useful right after you notice a reassignment happened.
That's a real trail, and it's more than most teams use. But it only tracks one field, and it only tracks who Jira calls the reporter. Changing that field takes nothing more than the standard "Edit work items" permission, so anyone on the team can reassign it, intentionally or by accident, with no special access required.
The other place to look is the epic itself. Stories attach to an epic through the Parent field, and here's the part that trips people up: unlike Reporter, the Parent field's JQL definition does not support WAS or CHANGED. You can query where a story's parent is today. You cannot query where it used to be. Once a story gets moved to a different epic, or an epic gets split into two, there is no built-in query to reconstruct which epic a story started life in. The only record is whatever a human wrote in a comment at the time, if anyone did.
“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 NotionA worked example
In March, a support engineer forwards a Slack thread to Devon Okafor, the PM who owns the Reports API roadmap: a customer at Halyard Systems needs bulk CSV export on their usage reports, blocking a renewal conversation. The support engineer doesn't have Jira access, so Devon files the ticket:
Devon, filing JIRA-482: "Add CSV export to Reports API. Customer needs to pull usage data into their own BI tool, blocking Q2 renewal per support thread 3/14."
Devon is the Reporter. Halyard Systems is a sentence in the description.
By July, JIRA-482 has become part of a bigger epic, "Reports API v2," after a re-scoping session folds three related requests together. The original description gets trimmed during that cleanup, because nobody's writing a new epic summary by hand from three old tickets' worth of context. In September, a different PM picks up the epic to plan Q4 and asks in the team channel: "does anyone remember who actually needed this?" Devon's since moved teams. The Reporter field says their name, correctly, but it doesn't say Halyard Systems, and the description that used to say it has been rewritten twice.
reporter WAS "devon" finds the ticket. It doesn't answer the question the new PM is asking, which is which customer, and whether that renewal happened.
Where the DIY fix runs out
The native fix most teams land on is a convention: a fixed line in the ticket description, something like Requested by: <account name>, filled in every time, plus a comment habit of linking back to the original Slack thread or support ticket instead of just paraphrasing it. Some teams add a dedicated custom field for "Requesting account" so it's searchable and doesn't live inside free text that gets edited.
This works as long as three things hold: everyone who files a ticket follows the convention, nobody rewrites the description without preserving that line, and issues don't get split, merged, or re-parented in a way that drops the line entirely. In a five-person team filing a dozen tickets a month, that's realistic. Once multiple PMs, support leads, and engineers are all capable of filing Jira issues, some of them will paraphrase instead of quoting, some will forget the line under deadline pressure, and epic splits will keep separating the customer name from the work that started it. The Atlassian Community's own writeup on connecting customer feedback to Jira puts the underlying problem plainly: "Customer insights live in Slack, sales notes, and support tickets, while the implementation lives in Jira. This 'feedback gap' creates a bottleneck." Even Jira Product Discovery, Atlassian's own intake tool, doesn't close it end to end. As that piece notes, JPD "lacks a way for customers to directly submit ideas," so someone still has to carry the context in by hand.
That's the point where the convention above stops being a process problem and becomes a structural one: a single free-text line can't survive being copy-edited by five different people over six months, and a single-value Reporter field can't hold "this was asked by four different companies," which is common once a request has been open long enough to become an epic.
What a context graph keeps that a Jira field can't
This is the specific gap Modem is built to close. Modem's Jira integration watches the projects you connect for new issues, updates, and comments. It doesn't stop there: it also reads Slack, support tickets, and call transcripts, matches the different ways one request gets phrased, and keeps every company and person that asked attached to the topic in a context graph, not typed into a field that a later edit can quietly erase. When that topic becomes a Jira epic or story, the requester list travels with it through re-parenting, splitting, and description rewrites, because it isn't stored in the description at all. Ask an agent "who asked for JIRA-482" six months from now and it answers from the graph, not from whatever survived the last edit. (This is what we sell. Treat the paragraph above as a checklist you can run against any tool, including ours.)
If your Jira volume is still small enough that one PM can hold the context in their head, the Reporter-field queries and a disciplined description convention will carry you a long way; that's genuinely the right starting point, covered in more detail in our guide on turning customer feedback into Jira tickets. Once several people are filing tickets and epics live for months before they ship, the convention is the part that breaks first, and that's the point to look at something that keeps the link outside the fields Jira lets anyone quietly edit.
Start this week
Run reporter CHANGED against your project today; it'll show you exactly how many tickets already have a filer who isn't the original one. For everything new, add one line to your ticket template: Requested by: with the account name, filled in at filing time, not after. That alone will save the next person who has to ask "wait, who needed this?" a lot of scrolling through comment history.
