How to create a Jira ticket from Slack without losing who asked

The fix is to stop treating Jira's Reporter field as the place the asker's name lives. Reporter is a reference to one existing Jira user, and in almost every Slack-to-Jira setup that user ends up being the bot account or whoever authorized the integration, not the person who typed the message. If you want to circle back to the original asker later, their identity has to go somewhere else, whether that's a dedicated custom field, the first line of the description, or a linked record outside Jira entirely, written in at creation time and not reconstructed from memory after the ticket has moved through two sprints.

Jira was built to track work, not requesters, and a Reporter field that can only hold a single Jira account was never going to double as a customer-relationship field. Here's what that means for how you actually wire Slack to Jira, and where the wiring tends to drop the one piece of information you built the automation to keep.

Two ways teams build this, and what each one keeps

A manual shortcut, run by whoever files the ticket. Someone reads a Slack thread, opens Jira, and types up an issue by hand, copying the customer's name and the thread link into the description. This works exactly as well as the person doing it is disciplined, and it's the default at small scale because it needs no setup at all.

An automation platform, watching a channel. Zapier and n8n both ship this as a first-class pairing. Zapier lists a "New Issue" trigger and a "Create Issue" action on its Jira Software Cloud integration, and names Jira plus Slack as one of its popular integration combinations. n8n's Jira node works the same way, with a Create operation that takes a Slack trigger's output and turns it into an issue with a project, summary, and description filled in automatically.

The automated version is the one that actually scales, and it's also the one where the requester disappears fastest, because the automation authenticates as one service account for every ticket it creates. Every issue that account can legally set as Reporter is itself. The Slack user's name is available in the trigger payload, sitting right there in the workflow, but it has to be deliberately mapped into a field that will still be visible six months later. Most builds skip that step, because the ticket gets created either way and the gap only shows up the first time someone needs to answer for it.

A worked example

Priya Lindqvist runs support engineering at Marlstone Instruments, a company that makes lab equipment control software. Their #customer-escalations Slack channel feeds a Zapier workflow, and any message tagged with a :ticket: reaction fires a zap that creates a Jira issue in the FIRMWARE project.

Priya, in #customer-escalations: Calibration Systems just emailed, their tech says the new firmware won't accept a batch export over 500 rows. They're mid-audit and need this by Friday. :ticket:

The zap runs. It sets the summary to the first line of the message, drops the full Slack permalink into the description, and creates FIRMWARE-891. Reporter shows up as Marlstone Automation, the Zapier connector's service account, because that's the account the zap authenticates as. Priya's name isn't on the ticket. Calibration Systems isn't on the ticket. Both are in the Slack thread the description links to, which is exactly where they stay until someone opens that link.

Six weeks later, engineering ships the fix and closes FIRMWARE-891. Nobody on the firmware team was in #customer-escalations in the original thread, so the close comment reads "fixed in 4.2.1" and nothing else. Calibration Systems finds out their audit blocker is resolved only when they happen to ask again, three weeks after the fact.

Where the DIY fix runs out

The obvious patch is a convention. Add a required field to the zap, something like Requested by, and map it from the Slack message's user object before the issue gets created. Practically, that means:

• Adding a lookup step that resolves the Slack user ID to a name and, ideally, a company.
• Making that field mandatory in the automation so a ticket can't be created without it.
• Training the team to fill it in by hand for the messages that don't come from the automated channel.

This holds up as long as one channel feeds one workflow and one person maintains it. It breaks down the way these things always do. A second channel gets added without the same lookup step, someone builds a parallel path through Slack's workflow builder that skips the field entirely, or the automation only has the Slack username, not the customer behind it, which is precisely the gap one n8n user ran into when trying to carry a submitter's email through a Slack-to-Jira pipeline. The intermediate step in their workflow didn't store the one field they needed downstream, and the thread closed with no fix in place. The same category of workflow shows up again in n8n's community forum for routing Jira approvals back through Slack, a different problem that still follows the same pattern. Teams end up hand-building the connective tissue between these two tools one workflow at a time, and every workflow is its own place for a field to get dropped.

The deeper issue is that "who asked" usually isn't one person. A request that starts as one Slack message from Calibration Systems often turns out to be the same complaint three other customers raised in three other threads, and a Requested by field on a Jira issue can hold exactly one value. By the time that pattern is visible, the convention above has already quietly lost the second and third asker.

Where Modem picks this up

Modem exists to close exactly this gap. Modem's Slack integration reads the channels you add it to, and its Jira integration watches your connected projects for new issues, updates, and comments, filing and updating tickets with the reporter, assignee, and source thread attached. The difference from a Zapier or n8n build is in where the requester lives. Instead of one Reporter field pointing at a service account, every person and company who raised a version of the same request stays attached to the underlying topic in a context graph, whether that's one Slack message or four, across however many channels it showed up in. When the Jira issue closes, that list is what you follow up against, not a single name typed into a custom field months earlier. Modem is what we sell here, so read that claim against the field of options, several of which are compared in the best tools for turning customer feedback into Jira tickets.

If your Jira volume is still small enough that one person can hold the context in their head, a disciplined Requested by field and a lookup step in your zap will carry you a long way, and that's a reasonable place to start. The point to look at something else is when a second channel or a second automation joins the first one, because that's when the convention stops being enforceable by any one person. The Reporter field has other limits worth knowing too, covered in our guide on how to see who actually asked for a Jira epic or story, which walks through what Jira's own audit trail can and can't reconstruct after the fact.

Check the mapping before you build anything else

Open your Slack-to-Jira zap or n8n workflow and look at whether the field that becomes Reporter or the description actually carries the original Slack user, or whether every ticket created in the last month shows the same service account. If it's the latter, add one mapped field for the requester's name before you add anything else. That single change decides whether closing the ticket also means someone gets told it's done.