How to create Jira or Linear tickets from Slack without losing who asked
Short answer. Create the ticket with the tracker's own Slack app (Jira Cloud for Slack, or Linear's Slack integration), then make sure the asker is written somewhere that survives: a "Requested by" block in the description with the person, their company, and a link to the Slack message, plus the Reporter field only if you deliberately map it. Jira's Reporter holds exactly one Jira user, and by default it is the account that created the ticket, which community reports say is the person who ran the Slack action, not whoever wrote the message. If you build the flow with Zapier or n8n, the API can set a Reporter by account ID, so the hard part is mapping a Slack user to a Jira account. And one ticket field cannot hold the second and third customer who raise the same problem in other threads. Modem (our product) covers that gap: it reads the Slack channels you add it to, groups the same ask from different threads into one topic with everyone who raised it, and files the Jira or Linear ticket when a teammate asks, with the requesters written into the body. It does not file on its own, and it does not set a structured Reporter or Customer field.
Slack is where the report happens, and Jira or Linear is where the work happens. The ticket exists the moment someone copies the message across, and the asker is the first thing to go missing. Six months later the fix ships and nobody has a list of people to tell.
What the native Slack apps do
Start here, because most teams do and it is free with the tracker you already pay for.
Jira Cloud for Slack (Atlassian's own app) has three entry points:
- A message action: hover over a message, choose More actions, then Create work item from Jira Cloud. With Rovo enabled, the action can read the full thread and pre-fill the summary and description. Rovo pre-fill does not run for the slash command.
@Jirain a channel or thread: Jira uses the conversation to fill in space, work type, summary, and description, and creates the work item immediately if every required field can be determined from context./jira create: a dialog with space, work type, summary, and description.
A work item created from Slack syncs the Slack thread with the item's comments, and an existing link can be synced later with "Sync with thread". Each person connects their own Atlassian account, and the app respects Jira permissions. See Atlassian's docs on creating and updating Jira work from Slack and syncing threads.
What the docs we reviewed do not say is who ends up as Reporter. Community reports say it is the user who ran the Slack action, and that Jira and Slack user IDs differ, so the author of the original message is not mapped automatically. Treat that as something to test in your own workspace, not a guarantee either way.
Linear's Slack integration works on every plan. You can create an issue from a message, with @Linear, or with /linear. The create dialog has an optional Customer field that pre-fills when Linear can determine the sender's domain, and the Slack thread and the issue's comments sync both ways, with the thread updated when the issue is completed or canceled. See Linear's Slack docs. Linear Asks (Business and Enterprise) adds intake for requests from Slack, email, and web forms, with entry points like the message menu, /asks, a ticket emoji, or an @Linear Asks mention; the submitter needs no Linear account. See Linear Asks in Slack. Linear's Customer Requests feature (on all plans) is the structured home for who asked: a request attaches one customer's feedback to an issue, so Linear has a structured home for this that Jira lacks out of the box.
Where "who asked" gets lost
Three things go wrong, and each has a fix you can apply today.
- Reporter is one person. It is a reference to one Jira user, set at creation. Jira records the creator and the reporter as separate values, so "created on behalf of" is possible, but it still points at a single account.
- The Slack author and the Jira account are different identities. Slack gives you a user ID. Name and email need a separate lookup with Slack's
users:read.emailscope, and the Jira side expects an account ID, not an email. - One ticket, many askers. The same problem is usually raised in several threads by several people. A Reporter or a single "Requested by" field holds one value, so the second and third askers vanish unless someone appends them.
Fixes, from cheapest to most work:
| Where the asker lives | What it keeps | Cost |
|---|---|---|
| A "Requested by" block at the top of the description | Name, company, date, and the Slack message link, in plain text anyone can read | Free; needs a convention or a template |
| A comment per additional asker | The second and third people, with their links | A person or automation has to remember to append |
| The thread sync (Jira) or synced thread (Linear) | Everything said in the thread, including who said it | Only covers people who replied in that one thread |
| A custom field (Jira) or Customer (Linear) | One structured value you can filter on | A field to maintain; still one value per ticket |
| Reporter set through the API | The asker as the Jira user of record | Needs the Modify Reporter permission (or Edit reporters on team-managed projects) and a Slack-to-Jira account mapping |
If you build it with Zapier or n8n
Zapier lists a "New Issue" trigger, a "New Issue (via JQL)" trigger, a "Create Issue" action, and a "Find or Create Issue" action on its Jira Software Cloud integration, and offers a template that creates Jira issues from new messages posted to a Slack channel. There is also a template that uses ChatGPT to turn a Slack request into a structured Jira issue.
n8n has a Slack Trigger node and a Jira Software node whose Create operation needs a project, an issue type, and a summary. Its Reporter field expects an account ID, not an email. User-contributed templates include one that parses a Slack message into a Jira issue and copies attachments and one that summarizes a Slack thread with an LLM and asks for approval with Slack buttons.
Both can carry the requester, and neither does it by default. The templates keep message text, a title, a description, and sometimes the Slack message ID. The requester only comes along if you add a Slack user lookup and map the result into a field. One n8n community user asked how to carry a submitter's email through a Slack-to-Jira pipeline; the gap there was Slack's email scope, and n8n has since added configurable Slack OAuth scopes so users:read.email can be requested. Setting the Reporter does not require a workaround in Jira either: its API accepts a reporter by account ID if the calling user has the Modify Reporter permission.
A build that keeps the asker:
- Pick one trigger. An emoji reaction or a mention filters intent. Creating a ticket from every message in a channel creates noise and test tickets.
- Look up the Slack user (name and email) from the message author, not from whoever triggered the zap.
- Map the result into the description's "Requested by" block, and into the Reporter only if you also resolve the Jira account ID.
- Include the message link so anyone can get back to the thread.
- Search before creating. If an open ticket already covers the problem, comment on it with the new asker instead of opening another.
- Post the ticket link back into the thread.
- Test with a second channel. The usual failure is a new channel added without the lookup step.
When the same ask comes from more than one thread
This is where a convention stops being enforceable by one person. A second channel gets added without the lookup, someone builds a parallel path in Slack's workflow builder, or three customers describe one bug in three threads and each becomes a ticket. You can keep it manageable by hand with a weekly pass: search the tracker for the error text or the feature's noun, close the newer duplicate with a link to the original, and move its askers over in a comment. See how to see who asked for a Jira epic or story for what Jira's own history can reconstruct, and turning a Slack thread into a Linear issue for the Linear version.
Where Modem fits
Modem reads messages and threads from the Slack channels you add it to: by invite, by mentioning @Modem, or by an auto-join rule for public channels whose names match a prefix you choose. Private channels are read only after a member shares them, and only from that point on. Direct messages are never read, live emoji reactions are not ingested, and connecting a public channel backfills 30 days. Reports that describe the same problem are grouped by meaning into one topic that keeps the original messages and the people and companies behind them, so "who asked" is the topic's list, not a single field. People are matched by exact email plus platform account, and companies come from the Slack workspace or work email domain.
Filing from a thread. Mention @Modem in the thread and ask it to create a Jira issue or a Linear issue. The agent reads the thread and writes the ticket. Only members of your Modem organization can use @Modem; customers and Slack Connect guests cannot, so a customer in a shared channel can't drive it. Modem files only when a teammate asks or an automation your team built runs. In Slack, a write like a Jira create waits on an Approve/Deny card for a linked org member, and a post into a Slack Connect channel does too. Routine internal writes such as a Linear issue are cleared by the default policy, and automations run without an approval prompt.
What lands in the ticket. Linear issues follow a template: the problem, context (channels, dates, who and which companies), up to three direct customer quotes, and a link back to the Modem topic. Jira has no template. The agent writes whatever your request asks for, so tell it to include who asked, their company, and the link to the Slack thread; nothing adds the thread link on its own. In both trackers the requesters and quotes are text in the body. Modem does not set a Jira Reporter or custom field to the customer, and it does not write into Linear's Customer Requests. If structured customer records on the issue are what you need, Linear's own Slack customer picker and Customer Requests do that natively, and Modem sits in front of them as the place the same ask from several threads is grouped.
Why it works this way. We built it because the context for a ticket lives in five threads and the ticket ends up saying "fix search." The body carries the problem, who is affected, and a few quotes, rather than a transcript dump, so an engineer sees a curated slice and clicks through to the topic for the rest. Slack approvals are a safety property, not a rollout choice: filing from Slack is a click, not a hands-off pipeline.
Limits. Modem reads only channels it is subscribed to, and a Slack workspace must expose emails for people to be linked by email; accounts without an email stay separate until merged by hand. A Jira integration is separate from Slack: it watches the projects you select in real time with no history import, and reads the reporter, matching to a Modem person by email when Jira returns one. Grouping is by an AI model and can be corrected by hand. For more on the Jira side, see the best tools for turning customer feedback into Jira tickets.
Public projects: keep customer names out
If you tell your team to paste the customer's name, email, or a private Slack link into a ticket, check who can see that project first. A public GitHub repository you track in, a Jira project visible to people outside your team, or any tracker shared with contractors or customers will expose whatever you paste. In those projects, keep names and private links out of the ticket and keep them in a private log keyed to the ticket number. A Modem create of an issue on a public GitHub repo shows an Approve/Deny card first for this reason: an issue on a public repo is a public statement in your company's name.
Check the setup before you build more
Create one ticket from each channel you use. Open it and look at three things: who is Reporter, whether the description names the person who wrote the Slack message and links back to it, and whether a second report of the same problem lands on the same ticket or opens a new one. Whichever of the three fails first is the one to fix before you add another channel or automation.
FAQ
Can Slack automatically create Jira or Linear tickets?
Yes, in two ways. Jira Cloud for Slack creates a work item when you mention @Jira and it can determine every required field from context, and Linear Asks can create issues from messages in configured channels. Zapier and n8n can create a ticket from every new message or a reaction. Creating from every message produces noise, so most teams trigger on a reaction or a mention.
Who is the reporter when I create a Jira ticket from Slack?
Atlassian's docs we reviewed don't say. Community reports say it is the person who ran the Slack action, not the author of the original message. To set a different Reporter through the API, pass the person's Jira account ID, and the calling user needs the Modify Reporter permission (Edit reporters on team-managed projects).
Can Zapier or n8n set the Jira reporter to the person who wrote the Slack message?
Yes, if you map it. Look up the Slack author's email with Slack's users:read.email scope, find the matching Jira account ID, and pass it as the Reporter. Most templates skip this, so the field defaults to the credential's user.
How do I keep the Slack thread on the ticket?
With Jira Cloud for Slack, a work item created from Slack syncs the thread with its comments, and "Sync with thread" does the same for an existing link, including earlier replies. Linear syncs the Slack thread and the issue's comments both ways. In a hand-built flow, include the message link in the description.
Can Modem create Jira tickets from Slack?
When a teammate mentions @Modem in a thread and asks, yes. It writes the ticket body, including who asked if you ask it to, and an Approve/Deny card appears in Slack before a Jira create goes through. It does not file on its own, and Jira has no Modem template, so the content depends on your request.
How do I tell the asker when the ticket is done?
Linear updates the synced Slack thread when the issue is completed or canceled. In Modem, an opt-in automation posts an internal Slack note naming who asked when a pull request directly linked to a topic merges. A merge is not a release, so wait for your release before writing to a customer.