Is there a way to give Jira Service Desk agents read only access to tickets? And to automate this?

Question

Hi, we have a workflow where the security level changes at each status via automation e.g.:

* Status 1 —> Security Level 1 —> Team 1 can access (+ edit)
* Status change: Status 1 —> Status 2 triggers an automation rule to update the security level
* Status 2 —> Security Level 2 —> Team 2 can access (+ edit), Team 1 can no longer view the ticket

However, we want to allow teams to still have read-only access to the Jira Service Desk ticket. In this example, we would Team 1 to have read-only access to the ticket at Status 2 / Security Level 2.

Is this possible?

Trevan Householder_Isos-Tech-Consulting_ · Answer

Hi @Charlotte Reynolds , yes, you can do this. @Arkadiusz Wroblewski is on the right track , and @Sarah Marenchino | Devoteam rightly separates visibility from editing. Keep Team 1 in Security Level 2 so they can still see the ticket. Then add a status property on Status 2: jira.permission.edit.group = Team 2's group ID.

Properties can only narrow permissions, never grant them, so the security level still controls who sees the ticket. For true read-only I'd also add jira.permission.comment.group = Team 2's group ID, and a "user is in group" condition on Status 2's transitions. Otherwise Team 1 can still comment and move the ticket.

Your existing automation stays as is. Test it on a copy of the workflow first.

Arkadiusz Wroblewski · Answer

Hello @Charlotte Reynolds

To build on Sarah's answer, you can use workflow status properties. Keep both teams at Security Level 2, and add the following to Status 2:

= Team 2's group ID

Team 1 will still be able to view it, while only Team 2 can edit it after the transition.

https://support.atlassian.com/jira-cloud-administration/docs/use-workflow-properties/

Cheers,

Arek🤠🧙‍♂️

Sarah Marenchino | Devoteam · Answer

Hi Charlotte,

Yes, this is possible, but there's an important distinction between Issue Security and Project Permissions in Jira Cloud.

Issue Security determines who can see an issue, while Project Permissions determine what users can do with it.

I would suggest the following approach:

* Keep Team 1 included in Security Level 2, so they retain visibility after the transition.
* Review the Permission Scheme to distinguish viewing permissions from editing and other write permissions.
* Use workflow restrictions where appropriate to control who can perform transitions or edit issues at each stage.

One important limitation: Issue Security cannot provide read-only access by itself, and project permissions aren't dynamically recalculated based on issue status.

Also, since you're working with JSM agents, be careful when modifying permissions assigned to the Service Desk Team role.

The key is to separate visibility, editing permissions, and workflow transitions, rather than relying on Security Levels alone.

Hope this helps!