Can Customers Vote on Feature Requests in the Jira Service Management Portal?
No, not on Jira Service Management Cloud or on Data Center versions before 4.15. The customer portal there has no native way for a customer to vote on a request the way they'd click a vote button on a public roadmap tool. The Vote field exists in Jira, but it's built for people with full Jira access, agents and internal team members, not for portal-only customers looking at their own requests in the help center. Data Center 4.15 and later added a limited version of portal voting, covered below.
The gap is documented and confirmed by Atlassian's own product team, not just community guesswork. Atlassian's public feature-request tracker has an open ticket titled "Ability to vote on an issue on Customer Portal," filed in April 2015, still marked Reviewing, sitting at 490 votes and 221 watchers as of this writing. Eleven years of a ticket asking for a voting feature, itself only rankable because the people asking happen to have Jira accounts, is the cleanest evidence there is that customers can't do this today.
“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 portal was built this way
Jira Service Management is a help desk, and the design follows from that. A solved thread on Atlassian's community forum puts it plainly, in an accepted answer from a longtime top community contributor: "Customers don't get access to the issues behind their requests. Voting is not something a service desk is expected to do." The core purpose of a service desk, in that same answer, is requesting help, change, or bug fixes, not ranking ideas. On Cloud, portal customers see their own request and its status. They don't see the underlying Jira issue, and voting lives on the issue, not the portal-facing request. (Data Center changes this starting in 4.15, covered next.)
This isn't an oversight Atlassian has ignored entirely. On Jira Service Management Data Center, the equivalent ticket (JSDSERVER-1743) shipped. JSM 4.15 added a version of portal voting in May 2023, and 5.9 refined it a month later to work through shared requests rather than a flat participant list. Cloud is the deployment most teams run today, and Cloud never got the same fix. If you're on Data Center and considering this, check your version against 4.15 before assuming it's missing.
What customers can actually do instead
Two mechanisms come close, and support teams often reach for them assuming they solve this:
- Request participants. A customer can add other people to their own request, and those participants get notified by email and can comment on it. It surfaces "who else is following this one request," but it's opt-in per request and only works if the customer already knows who else cares enough to ask them to join.
- Customer organizations. An admin creates an organization, adds customers to it, and shares a request with that organization so everyone in it can see and comment on the same ticket instead of each filing a separate one. That's three separate admin actions before a single customer sees anyone else's request, and none of them happen by default on a new JSM project.
Neither produces the thing a "can customers vote" question is usually asking about. What people want is a number you can sort by, per feature, across every request that mentions it. Here's who gets what, by deployment:
| Who | Can vote on the underlying issue | Can see others asking the same thing |
|---|---|---|
| Agents and internal Jira users | Yes, the standard Vote field | Yes, they work the queue directly |
| Portal customers, JSM Cloud | No | Only if added as a request participant or placed in a shared organization |
| Portal customers, JSM Data Center 4.15+ | Limited voting via shared requests | Yes, within the requests shared to their group |
| Portal customers, JSM Data Center pre-4.15 | No | Only via participants or organizations, same as Cloud |
Setting up organizations ahead of a launch, so the customers most likely to ask about a feature are already grouped, is the closest thing to a proactive fix available on Cloud today. It still depends on an admin predicting who'll ask before they ask.
A concrete case
Marcus Oyelaran has run support ops for three years at an infrastructure monitoring company with about 60 people on the team. Their JSM instance handles maybe 300 requests a month, and a chunk of those aren't bugs, they're customers asking for things the product doesn't do yet: custom alert thresholds, a Slack digest, SSO for a specific IdP.
Three different customers filed three separate requests about the same missing SSO provider inside one week. Marcus wanted to hand product one number, the kind he'd read straight off a roadmap board, something like "here's how many people are asking for this." Jira gave him three closed-looking tickets with three different reporters, no shared thread, and no vote count to point to. He ended up doing what a lot of JSM admins do in that spot. He manually reread the three requests, wrote a one-line summary in a Slack message to the product lead ("3 SSO asks this week, same provider, tagging here so it doesn't get lost"), and moved on to the next ticket in the queue. It worked, once. It doesn't scale to the next twenty features customers ask about the same way.
The limit of doing this by hand
Marcus's summary-in-Slack habit is the ceiling for the manual approach. It depends on someone happening to notice the pattern while triaging, remembering to write it down, and doing it again next month. Add in that customers also ask about the same feature over email, in a Slack Connect channel, or on a sales call, and a portal-only count wouldn't even be complete if JSM shipped one tomorrow. Vote tallies, where they exist elsewhere, only rank what showed up in that one tool.
That's roughly where Modem fits in. We build it, so factor that into how much weight you give the recommendation below. Instead of a vote button inside the portal, Modem reads JSM requests, replies, and internal notes the same way it reads Slack, email, and support conversations, and treats "we need SSO before rollout" and "any chance you support SSO" as the same underlying ask regardless of which channel or which of Marcus's three customers said it. The count becomes automatic, and it's attached to the accounts that asked rather than just a raw number, something like "SSO for [provider], 3 accounts, JSM plus one Slack Connect thread," with the original quotes and requesters kept alongside it. Details on the JSM side of that are on the Jira Service Management integration page.
If this keeps happening rather than being a one-off, two guides go deeper. The wider field of JSM feedback tools walks through options beyond Modem, and how to centralize customer feedback picks up the same problem once it's scattered across more than one support tool.
The short version
Portal customers cannot vote on requests in Jira Service Management today, on Cloud or on Data Center versions before 4.15. Request participants and organizations get you partial visibility into who else cares about one request, but neither produces a rankable count, and Atlassian's own eleven-year-old feature request for exactly this is the evidence that it isn't coming soon. If counting demand across requests, and across the other channels customers use, is the real goal, that's a job for something reading on top of JSM rather than a setting to enable inside it.
