Is it possible to add a custom "Like" button to JSM ticket screens for customer portals?

[Koki Hattori]

Hello,

I am building an internal idea-sharing portal using Jira Service Management (JSM)
on a cloud instance. The use case is as follows:

- Sales staff across the country submit customer requests and field ideas via JSM forms
- All portal customers can view each other's tickets
- We want users to "like" or "vote" on tickets they agree with,
so that popular requests can be automatically escalated

We are currently on a Premium plan.

---

What we have tried so far:

1. Vote feature
We looked for the vote feature under "Issue Features" in Jira Admin settings,
but could not find it in the current UI.
The URL /secure/admin/EditIssueFeatures!default.jspa returned a 404 error.
Is the vote feature still available in Jira Cloud? If so, where can we configure it?

2. Comment-based workaround
As a workaround, we set up an automation rule that detects comments containing
the keyword "いいね" (Japanese for "like") and increments a custom number field.
However, this approach is unreliable because:
- Some users respond with emoji instead of text
- Users may not read the manual and use different wording
- Duplicate "likes" from the same user cannot be prevented at the system level

---

What we are looking for:

We would like to know if any of the following options are available in JSM:

1. A native "like" or "vote" button on the customer portal ticket screen
2. A way to re-enable the vote feature that was available in classic Jira
3. Any recommended approach for collecting user reactions on JSM tickets
without relying on comment text parsing

Any guidance would be greatly appreciated.

Thank you.

[Trudy Claspill · Accepted solution]

Hello @Koki Hattori 

Welcome to the Atlassian community.

There is not a pre-built native feature for this. There is an open change request to which you can add your vote.

https://jira.atlassian.com/browse/JSDCLOUD-1743

Here is an idea, which I haven't had time to test.

Create a looping transition (from any status to itself) in the workflow.

Check the option to show the transition in the customer portal.

Customize the transition or use an automation rule to upvote the issue.

[Koki Hattori]

Hi @Trudy Claspill,

Thank you so much for your suggestion!

I was able to successfully create a "like" button on the customer portal
by using a looping transition — it worked exactly as you described.

I also added a check in the automation rule to store the user's account ID
in a custom field after they click the button. By verifying whether the ID
already exists in that field before incrementing the like count,
I was able to implement a one-vote-per-user restriction at the system level.

Your idea was really helpful. Thank you again!

[Arkadiusz Wroblewski · Accepted solution]

Hello @Koki Hattori 

Great writeup, you've clearly thought this through already. To add to what @Trudy Claspill  suggested, the looping transition idea is worth trying as a "vote" button on the portal, but there's one catch worth flagging: it wouldn't prevent duplicate votes from the same user.

Each time a customer clicks the transition, the automation would fire again with no native way to check whether that person has already voted

So to directly answer your questions: there's no native like/vote button on the JSM customer portal, the classic vote feature isn't available there, and preventing duplicate votes at the system level isn't possible natively.

If deduplication matters for your use case, a marketplace app would be the only reliable path. Otherwise, the looping transition approach combined with a clear label like "Vote for this idea" is probably your best native option accepting that vote counts may not be perfectly accurate.

Also make sure to vote on the feature request Trudy linked, the more votes it gets the more likely it is to be prioritised!

[Koki Hattori]

Hi @Arkadiusz Wroblewski  ,

Thank you for the thorough and honest response — I really appreciate it.

As you pointed out, I was aware that the looping transition approach
wouldn't natively prevent duplicate votes. However, I found a workaround:

I created a custom text field to store the account IDs of users who have
already voted. Each time the transition is triggered, the automation checks
whether the current user's ID already exists in that field.
If it does, the rule exits without incrementing the count.
This allowed me to implement a one-vote-per-user restriction
without any marketplace apps.

It may not be a perfect solution, but it works well enough for our use case.

I've also voted on the feature request that Trudy shared.
Hopefully it gets prioritized soon!

Thanks again for taking the time to respond.

[Arkadiusz Wroblewski]

@Koki Hattori 

Great to hear it worked 👍

It doesn’t have to be perfect, it just needs to work for your use case. If you’re happy with the result, that’s what counts.