JSM Portal-Only users access to Jira Product Discovery

[Rick Austin]

We use Jira Service Management (JSM) for our customer support portal allowing customer users to search and view documentation in the portion of Confluence exposed through our support site and to submit and track Jira support tickets.

We would like to enable all our customer users to submit ideas for product improvement into Jira Product Discovery (i.e. submit idea, find related ideas, upvote ideas, etc.). Reading up on the topic it's not clear if this is possible or not, to allow portal-only users to access JPD without a license. There is no way we can afford to license all our users for Atlassian for the infrequent case where the user needs to submit an idea.

Is it possible to enable portal-only users for access to JPD and if so, what steps would need to be taken? We are not using an IDP (i.e. SAML or otherwise) for managing user access, users log directly into their individual portal-only accounts. Thanks for any guidance, it would be much appreciated.

[Tanguy Crusson · Accepted solution]

Hi @Rick Austin , you can find what we support today here

Basically:

• You can publish a view but you currently can't share it with customers, just Atlassian accounts (we're planning to change that)
• They can't vote (we're also planning to change that)
• They can submit feedback via JSM (and then you add the tickets as insights in JPD)

We're currently in the middle of a project to improve all this. 

[Rick Austin]

Thank you @Tanguy Crusson, sounds exciting and looking forward to these future enhancements and would be happy to be an early adopter. Any idea on timeframe when this capability might land?

After doing a lot of further reading it does sound like what we are trying to do is possible, but with constraints. It starts with converting Portal-only users to Atlassian accounts and making sure the users are assigned a specific role so they can only access JPD and stay on free tier (we are not using SSO). Further research seemed to indicate there are some gotchas to navigate but they all sounded possible if we are able to live with the constraints.

Along the lines of...

1. Set up an isolated JPD project
2. Migrate a few test users to validate the concept and make sure access controls hold and confirm on billing page. Users migrated to jira-servicemanagement-customers-<workspace-name> with no default product access.
3. Add users to group we have granted JPD Contributor role and add that group to the JPD project. Assign Contributor role NOT product access (if you do, this would consume a license)
4. Convert users from Portal-only users to Atlassian accounts
5. Repeat above in waves

Downside and limitations

1. Voting on ideas is limited and will probably not work in the way we would like.
2. Comment attribution breaks (JDSCLOUD-7844)
3. Need to verify organization membership holds and if not reassign
4. Customer user now have site access, not just portal access so we have to be super careful we don't accidentally open up access.

Let me know if I am missing something. And please let me know if we can be early adopters of the new capabilities you are working on. Thank you.

[Rick Austin]

@Tanguy Crusson following up to see if you have a timeframe in mind for improvements. If in Q4, then we can wait, as we creep into 2027, we need a solution that our customers can use. Our ideal solution would be something like this...

1. JPD supports portal-only users
2. Users can submit ideas, feature requests, etc. As user enters feature request, it bounces what they are typing up against all other ideas to see if someone has already suggested the idea. Then the user can either select +1 the existing idea, add to it, or keep entering their own idea.
3. All ideas would be accessible by all portal-only users.
4. Our team would monitor ideas and do any association / correlation that makes sense.
5. For ideas gaining traction, we can associate the idea with a capability, epic, or backlog item and decided on provisional timing.
6. A feedback machanism to show when an idea was turned into a feature the customer can use in a certain release.

Probably a few more things but that's it in a nutshell. I know Microsoft had capabilities like this built in to some Office products, I have used other third party products. Would just like to stay within the Atlassian ecosystem to eliminate bi-directional integrations and keep us focused on what we do best, vs spending time integrating, maintaining, operating multiple solutions. Thanks for listening and hope to hear any news you can share on provisional availability (and we are happy to be a beta user).

[Aaron Pavez _ServiceRocket_]

Hi @Rick Austin and welcome to the Community.

I can think of two things:

1. An IDEA form and an automation in JSM that will copy the new idea to the JPD space.

2. If the users are internal, you can add them to JPD as a Contributor. Contributor doesnt need a license.

https://www.atlassian.com/software/jira/product-discovery/guides/getting-started/user-roles-permissions

3. If they are external, they need a Free Atlassian account and they can be stakeholders

Stakeholders must create a free Atlassian account to access a published view.

To learn more about roles and permissions, visit our documentation on product access and project roles.

Hope that helps!

Regards

[Olha Yevdokymova_SaaSJet]

Hi @Rick Austin 

Given the workflow you described, another approach you might consider while Atlassian is evolving the native JPD experience is Smart Forms for Jira, developed by my team.

I wouldn’t position it as a replacement for JPD — JPD can remain the source of truth for prioritization, roadmap decisions, and delivery. Smart Forms can provide the customer-facing intake layer without requiring your portal-only customers to become licensed Jira/JPD users and allows customers to create ideas.

A setup close to what you described could look like this:

1. Keep the customer in JSM

When a customer creates a particular JSM request type — or whenever you decide that additional product feedback is needed — you can attach a Feature / Product Idea Smart Form to that request.

The form can be:

- added automatically for selected request types;

- attached manually by an agent; or

- attached through Jira Automation when a specific trigger occurs.

With Jira Automation, you can also attach the form with values already known from the request, so the customer doesn't have to enter things like their account, product, request context, or other information twice.

2. Make the form available to the customer

The form can be visible in the JSM customer request, or you can share its external URL with the customer.

That means the customer doesn't need access to the JPD project itself to provide the idea.

3. Create the JPD Idea directly from the submission

In Smart Forms, the submission can be configured to create a new work item in your Jira Product Discovery project.

For example:

- Idea title → JPD Summary

- Problem / use case → Description

- Product area → JPD field

- Customer / account → JPD field

- Business impact → JPD field

- Original JSM request key → another field for traceability

So instead of collecting feedback in JSM and then manually recreating it in JPD, the customer submission can become a structured JPD Idea automatically.

4. Let customers check existing ideas before submitting

This part has also become more interesting with JPD's published views. Atlassian now supports publishing JPD views to anyone with the link, including people without an Atlassian account.

So you could place a link at the beginning of the Smart Form such as:

“Before submitting a new idea, check whether it already exists.”

Customers could search/filter the published JPD view, then return to the form if they still want to submit a new request.

There is still an important limitation here: published JPD views don't currently provide the full voting experience you're describing — Votes is one of the unsupported fields for published views. So this doesn't yet reproduce the UserVoice-style find similar → +1 → add context flow natively.

5. Close the loop after submission

You can customize the form submission message with next steps and include a link back to your published JPD ideas/roadmap view.

For a general external idea form, customers can also use Submit another response, so the same form can act as a persistent idea intake channel.

So conceptually the flow becomes:

JSM customer → Smart Form → JPD Idea → product team triage/prioritization → published JPD view for customer visibility

It won't solve the native deduplication-as-you-type and public voting parts of your ideal workflow yet, but it can solve the licensing/access problem and remove the need for a separate feedback platform or a JSM → JPD manual handoff.

For the votes you may try to use calculation field inside Smart Forms, but this is more like workaround you may need separate voting form, doesn't look like solution for me.

Happy to clarify how to create this set up with more screenshot or gifs to showcase how it works 😌

[Jens Schumacher - Released_so]

@Rick Austin you might also want to take a look at Released Hub in the Atlassian marketplace.

It already does everything you're asking for and more. 

Here is an example of a portal created with it: https://hub.released.so

[Sami Shaik]

Hi @Rick Austin , welcome, and @Aaron Pavez _ServiceRocket_ has the right map, so let me add the practitioner detail for your exact constraint, because your situation (portal-only customers, no IdP, no budget for licenses) has a clean answer.

The direct answer first: portal-only accounts cannot access JPD, and no configuration changes that. JPD has no customer portal, portal-only identities exist only inside JSM. So "enable portal-only users for JPD" as literally asked is a no, and the goal becomes delivering your requirements without customers ever touching JPD.

The build that does it, with zero new accounts: keep the front door where your customers already are.

1. Add a "Submit a product idea" request type in your JSM portal (fields matching what your product team wants: problem, impact, workaround)
2. An automation rule creates the linked JPD idea when one arrives (or your triage team promotes selectively), keeping JPD as the internal space it is designed to be
3. Demand counting instead of upvotes: when another customer raises the same idea, link the new request to the existing JPD idea and let automation increment a demand field on it. Your team sees "14 customers asked for this" as a number on the idea, which is honestly a stronger prioritisation signal than anonymous votes
4. Close the loop: when the idea ships or is declined, automation comments on all linked JSM requests, so every customer who asked hears the outcome in the portal they already log into

Customers submit, effectively vote, and get updates, all with their existing free portal accounts. Licensing cost for customers: zero.

If customers browsing and voting on the full idea list is truly non-negotiable, then Aaron's stakeholder route is the only path: JPD published views, with each customer creating a free Atlassian account (a separate identity from their portal-only account). That works, but it introduces a second login for every customer, which for infrequent idea-submitters is usually more friction than it is worth, which is why the portal-front-door pattern above tends to win in practice.