limit some Agents from working for some Organisations

[Stefan Unger]

Problem: my company has agents in countries all over the world. Some of our Customers (=Organisations) don't want that their Data is exported to some countries.

So I need to organize my Agents by country and my customers by their Data Privacy restrictions (also country based).

I did only find the "Issue Security"-Feature in Jira Service Desk, which allows a hyrachie but does not solve my problem.

How can I restrict my Agents to only see specific Organisations based on rules I attach to each Organisation?

[Dirk Ronsmans · Accepted solution]

Hi @Stefan Unger ,

The issue security should be the way to go here. It's not as clear cut tho.

Imho, you'll require a few automations to get this set up.

1. you'll need to design your issue security levels so that the correct agents are in there. This could be set up by just adding specific groups to a certain level.

2. You can indeed organize your customers in organizations and then you'll have to set up some automations to assign the correct issue security level based on the organization. 

I feel that would solve your requirements..

1. customer from a specific organization (this is defined manually) creates an issue and that issue is then automatically assigned a specific issue security level.

2. that security level only contains the correct groups/users.

Your security levels might get a little complicated since you have 2 requirements (country & data privacy) but you'll have to think about those.

Do keep in mind, even when an agent from another country is not viewing the issue, there is no guarantee that the data is not exported to another country. For an instance you can set up the data residency but that is not by issue/customer. So even when the user from another country isn't viewing it the data might still be "physically" in another country if you don't set up the data residency.

[Stefan Unger]

Wow, that was a fast answer. Thank you! I'm not 100% sure though it solves my problem.

Lets assume my Agents have a sucurity level based on their country:
German Agents - 49
French Agents - 33
UK Agents - 44

Now I have an organisation that allows 49 and 33.
Can I set more then one security level, when a ticket by this organisation is created?

[Dirk Ronsmans]

Hi @Stefan Unger ,

Sadly an issue can only have a single security level. So you cannot compound them on one issue.

You can solve this by either:

• Creating security levels that have all the combinations (a bit high maintenance but depends on how many  you need), so you'd have level:
  • UK
  • DE
  • FR
  • UK/DE
  • UK/FR
  • DE/FR

and then assign the users/groups to these levels.

Not the easiest to maintain if this changes a lot but that would work.

• Another way to do this could be to set up your security level based on a dynamic option.

When you set up your levels you could work with roles within the level or multiple roles? Meaning you add the agent to the role UK or DE or FR and on the issue security you can add the roles UK and DE for example.. but that would still be similar to the groups as you would need combined levels.

So I wonder if you could set a group of agents that have both UK/DE rights and then use that (or does that not work in your organisation?)

Otherwise you could look in to setting it up with the "group custom field" value and set that dynamically..

You'll still have some limitations but if the agents have multiple roles (meaning they are allowed to see a DE and UK ticket) the most straight forward would be to either grant them a role/put them in a group based on that if this can change from issue to issue to set up the combined levels and decide it based on the customer what level they get..

I did notice you information here that you specify the Free plan? If so, you won't be able to use issue level security (only from Standard up) so keep an eye on that.

[Stefan Unger]

Yes, I'm in the free plan trying to squeeze our processes/data model into the one of Jira. That is part of the reason I had to ask the question instead of just going trial and error with security levels.

With your answer I could setup Jira (a bit more complicated then I hoped...but the reason for this is not only Jira but also that our world got so complicated).

I'll close this one as solved. Thanks again for your help/detailed answer.