How to Handle New Feature Requests That Come In Through the JSM Portal
Give feature requests their own request type in the portal, route that request type to a queue nobody triages as if it were a bug, and enforce a single handoff rule. Nothing gets closed as "logged" without a link to wherever your product decisions actually get made. Jira Service Management doesn't do any of this for you by default. A portal customer picks whatever request type is closest to "something's wrong," an agent replies "thanks, I've noted this," and the ticket sits resolved with a note that nobody outside that queue will ever read again.
That's the honest starting point, because it's exactly the gap an admin raised on the Atlassian Community: how do you handle a request that needs actual development work, without either building a bespoke approval chain or letting it die as a solved ticket. There's no clean native answer in that thread. The best available replies lean on linked issues and automation rules, and even those hit a real snag. Hiding the approver field from customers doesn't fully work, so the workaround ends up exposing more of the internal process than it was supposed to hide. What follows is the version of that setup that holds up without needing a workaround for the workaround.
“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 NotionWhy the default portal setup treats every request the same
Most JSM portals ship configured around IT or customer support: "Report a problem," "Ask a question," maybe "Get help." A feature request forced through "Report a problem" gets triaged like a bug. Someone checks if it's reproducible, finds nothing broken, and closes it. Forced through "Ask a question," it gets answered and closed the same way. Either path ends at resolution, not at a product decision.
The first fix happens before any workflow change. Add a request type that exists only for this. Call it "Suggest a feature" or "Request an enhancement," give it its own icon in the portal so customers self-select correctly, and put one required field on the intake form asking what the customer is trying to do, not what's broken. That field matters because it keeps a feature request from ever being described in bug-report language in the first place.
What "logged" looks like without a shared queue
Take a support lead running JSM for a company that builds field-service software for warehouse robotics technicians. The portal has shipped with two request types for years: "Report an issue" and "General question." Every feature ask a customer has ever sent has landed inside "Report an issue," tagged resolved as soon as someone replies.
Customer, via the portal: Can the diagnostics export include the calibration timestamp? We're pasting it manually into every incident report right now.
The reflex reply closes it out: not a defect, so it's marked resolved with a note to pass it along, which in practice means a Slack message if and when someone remembers to send one. Nobody can say how many times that same export request has come in, because each instance lives under its own closed "issue" with no thread connecting them.
Once "Suggest a feature" exists as its own request type with its own queue, the reply changes along with where the ticket lives, to something like Logged as a feature request. I won't close this until it's linked to a tracked issue, and I'll update you here once it's picked up. The ticket stays open until it's linked to a Jira issue in the product backlog. That one rule, no closing without a link, is what turns "pass it along" from a habit into something checkable.
The queue and handoff, step by step
- Create the request type, scoped to its own portal group so it doesn't get buried under IT categories.
- Route it to a dedicated queue filtered on that request type, separate from the bug queue, so someone reviewing it isn't context-switching between "is this reproducible" and "is this worth building."
- Set a JQL filter or dashboard for anything in that queue past a few days without a linked issue. Atlassian's own guidance on routing linked-issue updates covers the automation piece once a link exists, but getting the link created in the first place is still a human step.
- Link, don't move. Create the engineering or product issue and link it back to the portal ticket rather than converting the ticket itself. Converting loses the customer-facing thread, which is the same problem covered in how to convert a JSM ticket into a development issue without losing the thread.
- Resolve the portal ticket only when the linked issue ships, with a reply that references what the customer actually asked for.
Three problems a request type doesn't solve
This gets a support team from "requests vanish into closed tickets" to "requests are visible and linked." It doesn't solve three problems that show up once volume climbs:
- Nobody's counting. Ten customers asking for the same export field shows up as ten separate tickets in the queue, each linked or not linked on its own. Nothing forces someone to notice they're the same ask, which is the same dedupe gap covered in merging duplicate JSM tickets from the same customer, except here it's ten different customers instead of one person resubmitting.
- The portal isn't where feature requests actually arrive. Some come in through Slack, some through a sales call, some through an account manager's inbox. A request type solves the portal's share of the problem and leaves the rest exactly as unstructured as before.
- Priority still needs a human. A queue and a link tell you a request exists and where it's tracked. They don't tell you whether it matters more than the nine other requests sitting in the same backlog, and JSM has no field for that either.
That's the point where a queue and a naming convention stop being enough, and something needs to sit above the portal, watching every channel a request could come from and counting them as one thing. That's the category Modem works in. It reads the JSM portal alongside Slack, email, and sales calls, folds repeated asks for the same thing into one topic with the requesting accounts attached, and opens the Linear or Jira issue itself with the customers' own wording already on it, no queue triage step for a person to skip. This is our own product, not an impartial pick, so read the paragraph above with that in mind. The request-type setup above is the right call regardless of what handles the rest.
Twenty minutes in the portal admin screen
Add one request type, "Suggest a feature," with a single required "what are you trying to do" field. Point it at its own queue. Tell the team the new rule out loud. Nothing in that queue closes without a linked issue. That's the whole fix, and it costs nothing beyond an admin config screen and one sentence in a team meeting.
