nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Jira for support handling

Niklas Jonsson1

My company have just started using Jira for development and we're planning to use jira for incoming support handling as well.

Our situation:

- 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..

Kind regards,

Niklas

Accepted answers

Taiwo Akindele

Hi Niklas,

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.

Further References:

How to configure automatic creation of issues via email: https://confluence.atlassian.com/display/JIRA/Creating+Issues+and+Comments+from+Email

In this mail handler configuration, you will also find how to enable automatic creation of new users from email.

All comments

Taiwo Akindele

Hi Niklas,

Further References:

How to configure automatic creation of issues via email: https://confluence.atlassian.com/display/JIRA/Creating+Issues+and+Comments+from+Email

In this mail handler configuration, you will also find how to enable automatic creation of new users from email.

Niklas Jonsson1

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?

Cheers, Niklas

Niklas Jonsson1

Taiwo, did you see my new questions? If you have time to answer them I would appreciate it a lot!

Thanks,

Niklas

Udo Brand

1. The security level Taiwo was speeking of can be used as default. So you don't need to set it manually

2. yes, you can log in simultaniously from different machines

Niklas Jonsson1

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!

Cheers, Niklas

Taiwo Akindele

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.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

jira-administration