nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

How to create a browsable, votable feature request portal in the Atlassian Environment?

Elias Sackmann

We would like to set up a portal or forum where employees can browse improvement ideas and vote for what they'd like to see implemented next - similar to Atlassian's own enhancement request project at https://jira.atlassian.com/browse/JSDCLOUD-1743 , where anyone can browse issues and click a prominent "Vote for this issue" button.

We're looking for this in Jira Cloud. We know the native vote button exists, but it's quite hidden in the issue sidebar and not obvious for less technical users.

What we need:

A browsable list/board of improvement ideas accessible to all employees
A prominent, easy-to-find vote button (not buried in the sidebar)
Ideally accessible without a full Jira license (portal-style)

Has anyone achieved something like this in Jira Cloud, Confluence Cloud, JSM or elsewhere within the Atlassian environment? Any recommendations would help here, thank you!

Accepted answers

Sami Shaik

@Elias Sackmann ,

What you are describing is the native shape of Jira Product Discovery, and the licensing works in your favour.

Why JPD rather than a Jira software space

Ideas live in a Discovery space with list, board and matrix views you control, so “a browsable list of improvement ideas” is a saved view, not a filter people have to find.
Votes is a built-in field on every idea, shown as a counter with its own button on the idea, not buried in a sidebar.
The people who only browse and vote are Contributors: per Atlassian’s access page, a Contributor “is an unlicensed user who doesn’t require app access to Jira Product Discovery”. Contributors can open the space read-only, add comments, insights, votes and reactions, and create ideas once a Creator switches that on (“By default, contributors can’t create ideas, but creators can enable contributors to do so”). They cannot edit ideas or fields, which is what you want for an employee-facing portal.
Only the product people who triage and edit ideas need Creator seats.

Two things to get right on day one

Grant Contributor access by group and keep that group out of JPD app access; the docs warn that adding app access to a group makes every member consume a licence. Contributors need an Atlassian account on your site, but not a JPD seat.
If you also want a link for people with no Atlassian account at all, Publish views gives a read-only link (Standard and Premium plans; a site admin has to enable it and the “Publish a view to anyone with the link” permission is separate). Note that Votes and Reactions are listed as fields that are not supported in published views, so voting stays with Contributors inside the space.

What it will not do

There is no “submit on behalf of someone else” button for contributors; ideas are created by the person logged in.
Votes are one per person per idea; if you need weighted or departmental voting, that is an insight or a custom field, not the vote button.

If you tell me whether employees already have Atlassian accounts on the site, I can be more specific about the access setup.

Refs: Manage your team app access, Publish views .

All comments

Sami Shaik

@Elias Sackmann ,

What you are describing is the native shape of Jira Product Discovery, and the licensing works in your favour.

Why JPD rather than a Jira software space

Ideas live in a Discovery space with list, board and matrix views you control, so “a browsable list of improvement ideas” is a saved view, not a filter people have to find.
Votes is a built-in field on every idea, shown as a counter with its own button on the idea, not buried in a sidebar.
The people who only browse and vote are Contributors: per Atlassian’s access page, a Contributor “is an unlicensed user who doesn’t require app access to Jira Product Discovery”. Contributors can open the space read-only, add comments, insights, votes and reactions, and create ideas once a Creator switches that on (“By default, contributors can’t create ideas, but creators can enable contributors to do so”). They cannot edit ideas or fields, which is what you want for an employee-facing portal.
Only the product people who triage and edit ideas need Creator seats.

Two things to get right on day one

Grant Contributor access by group and keep that group out of JPD app access; the docs warn that adding app access to a group makes every member consume a licence. Contributors need an Atlassian account on your site, but not a JPD seat.
If you also want a link for people with no Atlassian account at all, Publish views gives a read-only link (Standard and Premium plans; a site admin has to enable it and the “Publish a view to anyone with the link” permission is separate). Note that Votes and Reactions are listed as fields that are not supported in published views, so voting stays with Contributors inside the space.

What it will not do

There is no “submit on behalf of someone else” button for contributors; ideas are created by the person logged in.
Votes are one per person per idea; if you need weighted or departmental voting, that is an insight or a custom field, not the vote button.

If you tell me whether employees already have Atlassian accounts on the site, I can be more specific about the access setup.

Refs: Manage your team app access, Publish views .

Elias Sackmann

@Sami Shaik thank you for your help, we will definitely try this out!

Logan Vantrease

Hi, my name is Logan Vantrease,

A practical Jira Cloud approach is to create a dedicated project for improvement ideas, use a saved filter or board to make the requests easy to browse, and enable voting on those issues. Jira’s native Vote action can collect prioritization feedback, but it remains part of the issue experience, so it may not provide the prominent portal-style button you are looking for. A JSM customer portal can provide a more guided access model for users without full Jira access, although the available actions and visibility depend on the portal configuration and permissions.

Dashboard Hub Pro can provide the browsable presentation layer. It supports secure public dashboard links, so people can view shared dashboard content without access to the Jira or Confluence instance (` https://support.appfire.com/space/RDD/146310576?utm_source=atlassian-community&utm_medium=referral ` ). You can also share dashboards with JSM Customer Portal customers or organizations, and configure whether users can click through to Jira issues or only view the dashboard (` https://support.appfire.com/space/RDD/146309699?utm_source=atlassian-community&utm_medium=referral ` ). This makes it suitable for displaying an ideas backlog with summaries, statuses, priorities, and vote counts, but it does not itself create a separate voting workflow or replace Jira’s native vote action. You can find Dashboard Hub Pro on the Atlassian Marketplace ( https://marketplace.atlassian.com/apps/1223898/dashboard-hub-pro-charts-reports-time-in-status-for-jira ).

For a more table-like ideas directory, JXL can display Jira’s Votes field alongside summaries, statuses, priorities, and other issue fields. Its sheets can also be shared or embedded, depending on your access model. It would improve browsing and visibility, while voting would still need to happen through Jira’s issue functionality. You can review JXL’s documentation at https://jxl.app/docs/?utm_source=atlassian-community&utm_medium=referral and find it on the Atlassian Marketplace ( https://marketplace.atlassian.com/apps/1224710/jxl-sheets-hierarchy-structure-sum-up-time-in-status-table ).

Cheers,
Logan

Wesley Ede

Hi Elias, for the JSM route, the key is to sort out sharing first: employees need access to the same ideas before voting can be useful. I’d test that with two portal-only accounts before rolling it out.

I’m Wesley, the developer of Wezy Customer Voting for Jira Service Management. On company-managed JSM Cloud projects, agents can open selected requests for voting, and customers can vote or withdraw their vote directly in the portal. Your team can then compare votes and the organizations behind them in Jira.

This covers the portal voting part of your setup. Wezy keeps existing JSM permissions, so it won’t automatically create a catalogue visible to every employee.

Wezy Customer Voting on Atlassian Marketplace

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

confluence

jira

cloud

jira-cloud

confluence-cloud