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

Best practice methodology to setup JSM

Hello, I would like to determine the best practice methodology to setup & configure JSM for my Org.

We are a Technology team that has 3 underlying areas:

  • IT Operations
  • Software Engineering
  • ERP Services & Support

My question is; should I setup a JSM project for each of my "sub-areas" or should all services and support requests reside under one JSM project, and leverage custom workflows/screens to address specific forms depending on the issue type for each team?

Any feedback is much appreciated. We are working on leveraging Jira's features as much as possible to automate and reduce duplicate requests, integrate the KB in our overall company workflow.


1 answer

1 accepted

2 votes
Answer accepted
Dirk Ronsmans Community Leader Jun 24, 2021

Hey @Jaime Gonzalez ,

That's one hell of a question :) Let's see if I can add my 2 cents.

My first thought here was how do you want to interact with your customers? Imho a single portal (meaning a single project) might be the most user friendly if the customers see this as a one stop shop for all their support questions.

Do they actually know that there are multiple teams behind it or would this be a more general entry point with different Request Types?

Secondly, do these teams ever need to work together? Will there be a SPOC for most questions (like IT Operations will triage and pass it to the correct team?)

The way I often look at it, if they use the same workflows/screens then I like to try and keep a single portal within the help center with some Request Types and the default ITIL practices.

However, if they are basically all different and they have different reporting needs/permissions/flows/screens/... then I would consider actually splitting them up. Even if they all use an Incident Management process for example, if they differ that much in flows (which I hope they wont as it is a best practice standard) then management might become so horrible for the project that you are easier of just splitting it up.

I get that I might not be giving you a clear answer as to how you need to set it up, but I'd love to discuss it more and see how your requirements fit in to what you can set up :) With that little information it's not always easy to analyze the full impact and needs for your organisation.

I'd start by drawing up the flows you need and defining which processes will be relevant. Going from there you can see what the similarities and differences are and go from there to see if you need to split them or if it makes more sense to keep them together.

Analyze twice, implement once :)

Hi @Dirk Ronsmans. Thank you for replying.

The way we currently interact is, each of the 3 teams, directly gets assigned the flow of requests relative to them, as each team has an individual JSD project (these projects were created when it was still Jira Service Desk) I attached a screenshot of our current Customer Portal setup.Screen Shot 2021-06-24 at 6.07.13 p.m..png 

So the triage or SPOC part is not in the equation, we intend to keep it that way, as we are a small team. The teams do work together, we are improving our workflow now by adding issue links, KB references, etc, between software projects, JSM projects, confluence.

So what I wanted to do is remove the 3 old JSD projects and create a single JSM ITSM project to handle all support, incident, change requests. Trying to streamline the massive flow of requests coming in daily, both for users and support agents. And besides all, managing it all in one project.

Upon reading your response, I looked at it again and played with the request types a bit more. I sadly (because it was something so simple) found out that I can manage different views, for instance change requests, meaning I can have 5 different change forms using the same workflow, which is exactly what I need, and I don't have to custom anything.

Please excuse the long post for something so trivial; however, your perspective helped me figure this out. Thank you very much!

Like Dirk Ronsmans likes this
Dirk Ronsmans Community Leader Jun 25, 2021


Thats exactly what request types are for. Creating a specific form for a request type which will then be linked to an issue type. Having a many to one relationship like that helps keep down the number of issue types and avoid duplication to have a different form. 

with Atlassian’s acquisition of ThinkTilt(ProForma) this should only become even nicer!


Thank you for clarifying, hopefully this post will clear the way for some.

Just started using ProForma, its really cool

Suggest an answer

Log in or Sign up to answer
Site Admin

Atlassian Community Events