Customer (organization) level permissions for service desk agents

[Karan Patel]

We are trying to setup a service desk project for our customer. This will be the very first external helpdesk (support) we will have. 

Due to some security & compliance, our customer A would not want their data and service tickets to other customers & service desk agents who will be involved in other customers' tickets resolution.

I wonder if there is a way to achieve below - 

• 1 common service desk project for all new customers moving forward and add them as an Organization & add individual names (users) under the organization 
• Add lets say 5 service desk agents 
• Give service desk agents 1 & 2 the permissions to see tickets created by Organization A only 
• Give service desk agents 3 & 4 the permissions to see tickets created by Organization B only
• Give service desk agent 5 the permissions to see tickets created by Organization C only 
• Agents 3 & 4 cannot see tickets created by Organization A

Is this feasible to setup service desk agent roles & users permissions on individual organization/customer level?  

Thank you! Much appreciated your feedback/advice. 

[Mark Segall]

Hi @Karan Patel and welcome to the community!

I personally recommend separate projects.  The more you complicate your security environment, the more opportunity there is for something going wrong.  You can establish three unique projects.  To keep it simple for the customer, each should be configured to only allow customers who have been added by agents.  This way, each customer only sees the portal they're supposed to see.

Each project can use a shared configuration scheme, but the role assignments would be unique to each so that you can ensure only the agents that should have access have access.

Having stated that, it is technically possible to do what you're proposing with a consolidated experience. You'd need to employ issue level security and automation.  You could do something like this:

Set up your desired security levels.

Set up automation similar to this:

• TRIGGER: Issue Created
• IF CONDITION:  Organization = OrgIDA
  • ACTION: Edit Issue (Security Level 1)
• ELSE CONDITION: Organization = OrgIDB
  • ACTION: Edit Issue (Security Level 2)
• ELSE CONDITION: Organization = OrgIDC
  • ACTION: Edit Issue (Security Level 3)

[Patricia Francezi]

Hi @Karan Patel 

This is possible using Security Issue schemes + automation rules.

Its not that trivial to just post here in comments how to achieve that, but I suggest you a free training https://university.atlassian.com/student/activity/817156-issue-security-in-jira-asb-152-course-description

And also https://university.atlassian.com/student/activity/904430-manage-permissions-in-jira-cloud-skillbuilder-course-description

They work together. 

Plus - automation learning - you can find informations about basics in documentation. 

I hope this helps