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

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

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
Community showcase
Published in Jira Service Management

Atlympic Event: Jira Service Managemnt

Hello Community!  Quick disclaimer: We are running a contest on Community (The Atlympics!) from July 23rd - August 8th of 2021. If you are interested in participating in this contest (prizes! ...

121 views 0 2
Read article

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you