Hi All,
We are planning to create a new Sevice Desk in our Jira such that, there are 3 locations, say A, B, C. Each location has its own service desk customers and agents. We do not want the request/ticket raised by a customer/agent from location A to be visible by any agent/customer from B or C and vice versa. Could you please help us to implement the same condition?
Why would Organizations not work here? Associating an org to each location.
Hi @SWATHI RS ,
This would need a 2 prone approach.
1) Customers:
you can add those customers based on the location in separate organizations. Then they are able to launch requests private or shared with their organization. (by default if you don't use organizations everything is private anyway meaning only viewable by the person that created it)
https://confluence.atlassian.com/servicedeskserver/adding-customers-939926467.html
2) Agents:
Within one project there is no permissions to limit the access of an agent. The workaround here could be separate security levels.
By placing the security level on the issue at creation you can limit which agent sees what issue.
https://confluence.atlassian.com/adminjiraserver/configuring-issue-level-security-938847117.html
the only tricky thing might be how to set the correct security level at creation.
You could opt to have a group of users that can see everything as long as there is no security level and have those "first group of users" triage them to the correct agents. Otherwise you might need to look at some automation to set it at the start.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I'm happy to get all suggestions for my question here and quite liked the detailed explanations from both @Dirk Ronsmans and @Harshit Goyal But, I have a concern related to the solution related to components. How is the customer able to select the component? And if the ticket is raised as an email request by customer, how will the ticket get assigned as that component? Will that require an automation to fetch keyword 'A' in his email?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi SWATHI RS,
You can create multiple Service desk project based upon the location and accordingly define browse permission to restrict the visibilty of agents. I guess this is the simplest solution you can try.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Harshit,
Thanks for the fast response. I can think of think of that. But, is there any possibiliy of implementing this within one single project?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You can also explore the component option,
Based upon the locations you can create components in that project and decide the assignee of that ticket. So, if your customer select option A from component list then it shall be assigned to a person in location A and by giving assignable permission the current assignee can transfer the issue to someone else if required.
Also, If you restrict the browse permission to assignee and the administrators, the agents won't be able to see each others ticket and will only see the tickets assigned to them.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
also a nice approach.
Depending on the use case this might be too restrictive tho. It depends whether agents from the "same location" are allowed to see each others tickets too.
The component (or another custom field on the request form) might be a good way to automate the assignment (or in my case the security level through an automation).
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
It feels good to get a compliment from Community Leader Dirk Ronsmans :)
As, you have mentioned it depends upon the use case and your suggestion for the use of issue level security is also good but don't you think adding customers restricts an individual to limited number of clients or I'll have to dig much more deeper into it.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Haha don't let it go to my head :)
I don't really understand what you mean by "adding customers restricts an individual to limited number of clients"
Customers don't count towards your license and can be neatly organized in organizations. (and a customer can be in multiple organisations)
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Online forums and learning are now in one easy-to-use experience.
By continuing, you accept the updated Community Terms of Use and acknowledge the Privacy Policy. Your public name, photo, and achievements may be publicly visible and available in search engines.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.