JSM project connected to a Jira Software project?

[Darryl St_ Pierre]

I'm trying to link a company-managed service desk project to a backend software (or service desk) project (preferably team-managed).

I ran across this discussion: Connecting a Service Desk to a Classic Software JIRA project 

but it doesn't address a significant need we have - collecting data that would be mapped to the backend project for reporting.

Our use case:

We have a department, currently hosting a service desk, that wants significant custom field additions and complex workflows. My thought was to setup the backend project as team-managed so that there are few to no global system changes required. The SD agent would maintain all communications with the requester via the original ticket, but all the work would be managed in the backend.

We would collect all the necessary information up front through the use of a form. The problem is that only the standard fields in the front end project can be mapped (to my knowledge). The custom fields that only exist in the backend would not be visible to map. 

Is there functionality or an app that I'm missing that could accomplish what I'm trying to do?

[Curt Holley]

Hi @Darryl St_ Pierre 
I'm struggling to understand exactly what you are after, but if you want to do "syncing", "Cloning" of tickets between projects, making them all company managed is going to make that kind of trickery a lot easier.
As you have alluded to "The problem is that only the standard fields in the front end project can be mapped" which means your Front end must be team managed.

Team managed, as the name suggests, are really only good for a team to manage with complete autonomy. I.E. they do not need to integrate with any other project, system or even reporting.

If you wanna go down this path, make both project company managed. More work up front, sure. But means you can integrate them and in a more controllable way.

[Matthias Gaiser _K15t_]

Hey @Darryl St_ Pierre

I'm in a similar boat like Curt that I don't fully understand your use case.

Can you describe why you want to have two projects at all? Is this to have a simplified workflow for your agents?

I throw in some of my thoughts to see if they help you for a solution:

• You could also create a team-managed JSM project and they could directly model their fields in there.
• Your could create a JSM form which collects additional data without creating additional custom fields.

Maybe that helps to inspire a solution.

Cheers,
Matthias.

[Darryl St_ Pierre]

@Curt Holley and @Matthias Gaiser _K15t_ , thank you for your feedback. I will try to explain better where my logic (or lack thereof) lies...

We host close to two dozen departmental service desks in our environment, and all are company managed. Until recently one was team managed, and it was creating problems when tickets needed to be transferred from or to another service desk. Request types/issue types were difficult to match up, and there was often a great disparity in required fields. We have enough instances where tickets need to be moved for this to be a consideration.

We're trying to keep global system configurations, e.g. - fields, Statuses, issue types, as standard and out of the box as we can to reduce maintenance and avoid confusion for the end users. Perhaps this is an unrealistic goal, but we have very limited resources maintaining multiple Atlassian products.

In keeping with the above, I thought the best solution would be two projects. The front end project already exists and has been running for a couple of years, but they now want changes to accomplish more granular reporting. The changes would require the creation of multiple custom fields and niche Statuses, both of which would likely not be used outside of the second (new) project.

Based on both of your responses, it sounds like I really need to make a decision between company-managed and team-managed and accept the trade-offs.

[Curt Holley]

From what you have said @Darryl St_ Pierre I would suggest you just need to stick to Company managed, then the tickets can flow between all your JSM projects.
Yes, ideally they all use the same core set of fields, but there can be exceptions. 
Same with workflows. It is great if they can all use the same, but if not, fear not. As long as there are some core ones that mean sharing isn't too complicated, letting some projects have more status options isn't so bad.

But when they are created on the fly in team managed, that is when you end up with duplication (of fields and statuses), confusion and compromise when trying to move, filter or report, or automate such things.