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

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

Avatar

1 badge earned

Collect

Participate in fun challenges

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

Challenges
Coins

Gift kudos to your peers

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

Recognition
Ribbon

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!

Leaderboard

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
4,463,509
Community Members
 
Community Events
176
Community Groups

Sharing issues efficiently across multiplie JSM projects

Hello Everyone,

 

Background: My organization has 9 service desk projects. We have created them by department and we populate Jira licensed users with our Microsoft AZURE AD groups that are used for other applications as well. Currently only department members have access to their department service desk projects. For example, Technology department team members have access tot heir own project, but not to Payroll or Human Resources, and vice versa.

 

Scenario: A service request is submitted by a user to the Technology Service Desk. The request is for account access to organization applications. The Technology team member that is assigned to this issue has to complete some steps to prove account access. One step needs to go to the Payroll department and another needs to go to the Human Resources department, then back to the Technology department to finalize and resolve the request.

 

What we currently do: Currently we decided not to move the issue between service desks. Doing this creates new ticket ID's and the original assignee that is responsible for this request in the Technology department will no longer be able to access the issue if it is moved.

So we use the Requested participants field to add a contact for each department and then that participant will comment when they are completed with their step in the request. The Technology team member will then resolve.

This is not ideal because as a requested participant they only get the portal view of the ticket and since they have a license to another project, they get an error saying they do not have access. so they have to go view the comment in the customer portal or reply via email. This is confusing.

We do not want to give other department members permission to every project they interact with if we do not have to. We did this in the server version before we moved to the cloud and the feedback was that the other departments working in our project were confused and they wanted their own.

 

What can we do?

I am wondering if there are organizations out there with multiple department service desks and how they handle working on requests that may cross projects? What are the best practices? Also if they are moving the issues between each project, how to you track that, how do you stop the "passing of the trash".


Thank you so much and looking forward to your feedback.

2 comments

Mikael Sandberg Community Leader Jul 21, 2022

We have sort of a mix, in some JSM projects we give others access to the project, for example in HR we are using issue security to give IT access to only see onboarding/off-boarding requests and sub-tasks. Another example in HR when they need IT to review a change they have a status for IT Review, and when moving the request to it it generate a request in the IT project.

Like William Johnson likes this

Thank you Mikael. Issue security seems interesting. Did you have any pain points from the IT members that have the permissions to go in the HR project and locate the issues? 

In our situation our IT team has been using Jira for over 4 years. So they may not worry too much about going into other projects. However, for the the departments that need to view IT issues, that may cause some confusion due to the lack of knowledge of using Jira

Like Mikael Sandberg likes this
Mikael Sandberg Community Leader Jul 21, 2022

No, no pain points using issue security. We have multiple teams accessing the onboarding/off-boarding requests in HR and so far everything is working as expected. I use a default issue security that is a generic on, and then have an automation that sets it so only the reporter and HR can see all the other requests.

So we have a similar situation, in we have distributed IT groups that we have separate projects setup.  We did go the direction of running an manual automation that clones the issue to a new project, links the 2 issues and marks the original Done.  We send a communication to the customer letting know that this has occurred and they will see a new issue number.  We provide our Service Desk the ability to view into the other projects so if they get a call they can provide a status update to the customer and comment on the issue that the customer called.  This has worked pretty well for us and helps provide good tracking on where issues start and end.

Like # people like this

Thank you Alan. I was thinking about automation as well. Is the communication you send to the user about the new issue number a step in the automation during the closing?

This would be helpful for most of our use cases. I have a series of moving issue automations built currently that change the status and set the assignee to unassigned. I could add some more to it like you describe.

Yes.  The automation send the email for the closing issue.  The Clone issue has emails sent from the project email options for a newly opened issue for the other project.

Comment

Log in or Sign up to comment
TAGS

Atlassian Community Events