Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

Strategy question how to set up Jira Service desk projects for multiple customers.

I have multiple customers we provide systems support to.  I receive system alerts into Jira via email, and create tickets.  I have Organizations which each have their own email sending alerts to Jira.  In addition, I plan to have a customer portal for each.  I believe/assume I can leverage Organization to keep my customers and related issues separate.

Two questions.

1) Should I set up one project for multiple customers, or a separate project for each?  The resources working on the tickets are the same either way, at this point.  My thinking is that one project would be easier to maintain; however, what are the things I should consider?

2) Similar question for automation.  I am creating automation rules based on the subject line and in some cases, the body of the email.  The logic applies to all customers, with some slight variations.  Should I set up one big rule with multiple if then's, or separate rules?

Thank you,



Hey Paul,

Are the email addresses your customers sending to going to be different or the same? If you have one submittal address, you can get away with one project, but more than one submitting email address will require another desk (or at least some forwarding rules which makes things messy). 

Separate desks are also the only way to get more than one portal.

As for setting up automation rules, I find that it's easier to manage a smaller subset or rules, and you have a cleaner end-result, but separate rules could be easier to troubleshoot out of the gate. 

If you are creating separate projects, you will likely want to separate the rules. 

Hi Meg,

Thanks for your response.  The emails are sent to a central Outlook email and then Jira pulls the emails based on who the sender is, each having their own email.  So I receive it in Jira as if it came from the customers server.  So that email is part of the organization.

I am assuming that I can have a shared portal, with the individual contacts associated with their organization.  Thus I should be able to track requests by organization, etc. Let me know if you think that could be problematic.



Hey Paul, 

If you only have one help desk email channel, you can only have one portal. 

If you want more than one portal, you will need a separate email account for each help portal. 


If you have users set to specific organizations, I do believe you can find ways to tie together the organizations to default issue types, which would allow you to administer multiple customers from one desk. 

Jack Brickey Community Leader Mar 23, 2018

to add to this. if you create two different projects and use different Organizations/Customers per project then, while you have only one portal, the projects will have their own unique URL, e.g. .....portal/1 and .....portal/2.


Can you elaborate on how I might tie the organizations together to default issue types?  I am not able to change the issue type with an automation rule.



Hey Paul, I can try to look into out of the box functionality for JIRA sometime next week, but I can recommend Automation for JIRA if you are looking for an addon with lots of highly-configurable automation settings. 

Jack Brickey Community Leader Mar 23, 2018

@Paul Neat, i don't understand the goal of associating an org to an issue type.

@Meg Holbrook, not trying to butt in here. just trying to help if I can. :-)

No problem at all, happy to see what other people might do. 

My interpretation of this was that Paul wanted one single help desk where users from a differnt orgs could submit to one help desk but default those orgs to different 'types' 

Thanks all for your comments. Here is what I am trying to do...

I have several customers with systems monitoring events.  Those events are emailed to a central email box.  Jira pulls the emails and I can associate the email with an organization as each organization has a unique email which I see in the From field when I receive the email in Jira.  I am motivated to have one big project to handle the events as the automation rules are largely the same for all customers, and will be lengthy and complex.  For example, if the subject line says x, change the priority to Highest and escalate the issue, or if it says y, transition the issue to canceled, etc...

Meanwhile, I want to have a portal for our customers to make various service requests.  The emails are tagged with one Issue type.  Ideally I want an email associated with an issue type for events and an email associated with an issue type for customer request.  Thus I am thinking I would need to have two projects, one for each.  When a customer logs a request on the portal it is currently tagged as an event issue type.  I am not able to create an automation rule that changes the issue type to a customer request - I receive a message basically saying you cant change issue types. (perhaps I am doing something incorrectly)

I appreciate any perspective and guidance you can provide.  I am open to any ideas as I may be thinking about this the wrong way....




Jack Brickey Community Leader Mar 23, 2018

Thanks Paul that helps. So first I agree w/ you on a single project as it will be easier for your team since all agents work on all issues. If you had separate teams working events and 'portal issues' then i would like suggest two projects.

Now to be clear let's keep "Issue Types" separate from "Request Types". Issue types are like Task, Bug, Incident, etc. Whereas Request Types are what the customer will see in the Portal. You likely are already aware but just making sure we use the same language.

It sounds like you are using some email parsing which is really good because it will allow you to appropriately set fields on incoming issues reported to keep stuff straight. OOTB this is a bit limited in JSD, at least in Cloud. If you could dedicate the email channel for events from the monitoring system and the portal channel for everything else that would improve things here quite a bit but w/ email parsing you could deal w/ both events from monitoring systems and customers sending in emails for issues. The point here is I think you will want to separate these into different Request Types, e.g. System Events, Question, Bug, Enhancement, etc. I have a Request Type call IT-Email and I hide that from the portal as it is dedicated to the email channel all other Request Types are visible and grouped to make it easy for customers in hopes they 'get it right' when they open a ticket.

Now if you are in fact using Issue Type for things like Events, etc that might be just fine but maybe unnecessary. If you can dedicate the email to these "Events" then certainly having that be an Issue Type makes sense. One possible reason you likely can't change the Issue type as you mentioned is the from/to issue types have different workflows in which case a Move is required. Or it could be a permissions thing. 

Finally, if you really want two emails then you are talking two projects. But if you can parse the incoming and direct events to "Events" and all non-events to "Customer Req" issue type then you can stick w/ one project. The question to ask yourself is whether the workflow for dealing w/ Events needs to be different than "Customer Req". If they can be the same then I would content that using a single issue type and two request types might be better, but that is very objective.

Unsure if any of this helps. There are a number of ways to set JSD up.

Thank you Jack - very helpful.  I will hide the email request option from the portal - good idea.  But if I understand it correctly, if a customer emails a request directly to the Jira email, I will still have the issue of 'conflict' with the events and customer requests coming through the same email, which will have the same Issue type and associated workflow.  I anticipate I can use the same workflow for each; however, for reporting purposes I want to be able to distinguish events from customer requests.  Events are internal and only a subset are escalated to the the customer.  Customer requests certainly will involve a back and forth, status reporting, etc.  Both are reported on a monthly summary report.  So my challenge is how to separate the two?  Is there a way to effectively do so without setting up a second project for customer requests?



Log in or Sign up to comment

Atlassian Community Events