Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


How can I give some users limited Service Desk Access and other users full Jira access - while still

How can I give some users limited Service Desk Access and other users full Jira access - while still keeping all of their approver roles and moving issues through the workflow?

There are sensitive payroll/bonus related tickets that only a select few should see. Those people would need to see tickets assigned to them, be able to approve/deny them and move them along in the workflow without being able to see any other tickets or issues within the project.

My understanding is that these people who need limited access require only Service Desk Access.

There are others (managers/directors/etc) who should have full back-end Jira access to see everything.

Can this be done? If so- how?


I've looked into creating an ISSUE SECURITY SCHEME but these aren't very clear and I've yet to see where I can assign a specific payroll/bonus ticket type to them scheme. It seems as though you can apply an ISSUE SECURITY SCHEME to a PROJECT, but not an ISSUE (which doesn't make sense to me.)

I've also tried putting users in either SERVICE DESK TEAM (which has full back-end Jira access) and SERVICE DESK CUSTOMER (limited access) for their roles, but then various approval buttons and other workflow missteps happened.

Is it a matter of going to the PROJECT PERMISSIONS area and adding indiviudal names in either the "Browse Projects", "Assign Issues", "Edit Issues", "Transition Issues", etc.?

1 answer

0 votes
Stephen Wright _Elabor8_
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
May 07, 2022

Hi @Michael Miller 

It looks like there are a few requests here:

  • Access to Jira vs Jira Service Management
  • Restricting access to Issues of a sensitive nature
  • Ensure Approvers remain working


Jira vs Jira Service Management Access

In simple terms...

  • Users need a Jira licence to use Jira Software, and a Service Agent licence to use Jira Service Management
  • JSW users can see Issues in JSM Projects, unless you limit their access using the Project's Permissions

So for example, you could modify the Permission Scheme for the JSM Project to restrict Browse Projects access to...

  • Service Project Customer - Portal Access
  • Specific Project Roles - such as the Service Desk Team - so you can limit who can see the Agent's view via Project Settings > People


Restricting Issue Access

Assuming this is from within the Agent view...

You are correct that Issue Security Schemes can do this. You'd need a method to...

  • identify Issues of a sensitive nature - such as an Issue Type, or Request Type
  • identify who should be able to see the Issue from within the Service Desk Team - for example is this always the Assignee? Or the creator/reporter? Or are these issues assigned to a specific user? Etc

You can then create your Issue Security Scheme:

  1. Go to Jira Settings > Issues > Issue Security Schemes
  2. Create a new Scheme using the add button
  3. Once created, on the right-hand side of row next to your Scheme, select the hyperlink Add Security Levels
  4. Create a new level - for example Sensitive Access
  5. Once created, on the right-hand side, select Add
  6. Add a user type to this Security level - for example, it could be they're only visible to a Single User, Assignee, or the Reporter, or perhaps a Group of users?
  7. Continue to add additional user types to the Security level as needed - for example, if Jira Admins should see these Issues, or a Group of senior managers.
  8. Apply this Scheme to your Project

Once the Security Scheme is live, you need to decide how to apply it. As these tickets could be sensitive from creation - I would ensure they're restricted immediately. To do this, I would...

  • Ensure someone can see the Issue post-creation, if it's not Assigned automatically - for example, the senior managers Group.
  • Use an Automation rule to set the Security Level during creation - for example:
    • Trigger: Issue Created
    • Condition: Issue Fields Condition
      • Request Type = Payroll
    • Action: Edit Issue
      • Security Level = Sensitive Access

Assuming Assignee is applied to the Security Level, you could then assignee the ticket to a user, and it'll be visible to them. But before that, it would be hidden.

You can also make the Security Level the default at creation from the main list of Security Levels, if all tickets should be limited in this way.



This isn't linked to the Issue Security Scheme directly - apart from the fact a user needs to be able to see the Issue if they're going to approve it, edit it, transition it, etc.

Approvers are managed via the Workflow - i.e.

  • Modify the relevant Workflow, and check Add approval" when selecting a relevant Status
  • Get approvers from a relevant field
    • If the Assignee is the Approver, you could use Automation to copy the user to a custom user picker field (such as Approvers), then use that in the approval process


Let us know if the above helps - or, if you have any further questions!


Suggest an answer

Log in or Sign up to answer
AUG Leaders

Atlassian Community Events