My company have just started using Jira for development and we're planning to use jira for incoming support handling as well.
- Multiple customers where some should be able to log in to Jira and create issues themselves.
- Ability for us to create issues from emails and phone calls from customers not entering their own issues directly into Jira.
My initial thought is to have one project for all support handling and then use permissions so that each customer only can see their own issues.
Question 1: Does this sound like a good setup? Any reasons for not doing it in this way? Better to have one project per customers?
Question 2: What is the standard way to handle users for support? Does each customer get one generic user for Jira? Or should one Jira user be created for each customer person? I guess the number of users easily could grow very quickly if we go for the second alternative = need to buy a more expensive license.
Question 3: If using one support project for all customers. Is there any recommended way to separate customers? Custom fields? Components? Something else? Since some customers should be able to create cases themselves it feels strange to let them specify which customer they are in a field..
1. Yes, you can choose to use one project for all support handling and use Issue Level Security to restrict users to only their own issues. Having one project per customer for Support Handling may not be a good idea as you would probably have too many projects to manage, if you have a lot of customers.
2. Ideally you should have a user account per customer, this way it is easy to track all issues or support cases related to a particular customer for instance. But not all user accounts need to be able to login. Only users who are able to login to JIRA will count towards your license.
3. Issue Level Security as I mentioned earlier allows you to specify that all issues in a project should be restricted to the reporter (customer who raised the support ticket) and Support Staff, for instance.
In this mail handler configuration, you will also find how to enable automatic creation of new users from email.
Thanks a lot for your answers Taiwo! Some follow up issues:
1. Do you manually have to set the issue level security per issue or will this be handled automatically with a proper scheme?
2. When saying user account, do you mean a standard jira user then? So for instance; if Customer A have three persons that should be able to create issues in our Jira they should all use the same user? Can one Jira user then be logged in simultaneously from three computers?
When looking in issue security levels a little more I got confused. Do I really need this for my setup? (that a customer should only be able to see and edit his own issues) As far as I can see this could be handled using permission scheme. In permission schemes you can specify that only the reporter should be able to browse an project and edit issues etctera. Shouldn't this be enough?
Guess I just miss why I should use issue security, and it seems to be pretty straight forward to set it up, but just want to keep my setup as easy as possible!
Hi Niklas, sorry I couldn't follow up on this back then. Just adding a comment now that I came across this again for benefit of others, so I hope this answers your question.
The permissions controlled in the permission scheme are mostly on a project level. So if you are using common projects (i.e. your project is not restricted to a particular customer) for customer support, and you grant the browse project permissions. Different customers will generally be able to see other customers issues.
Also, granting/restricting edit issues permission in the permission scheme here simply means that, all/no customers would be able to edit issues generally in the project respectively (regardless of whether it's their own issues or other customer's issues).
So, the reason why you need Issue Level Security here is to restrict who can access each particular issue in the generally accessible project to specific users (e.g reporter/assignee/any named user in the security level), project roles or groups. This you cannot do from the permission scheme.
In the past, Portfolio for Jira required a high degree of detail–foresight that was unrealistic for many businesses to have–in order to produce a reliable long-term roadmap. We're tur...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG