We have a Support project that's used as a generic intake location for all sorts of issues. Very often, the reporter submits the wrong ticket type, and we need to Move the issue into the correct place. (75% of the time or more)
We have 20+ projects and 30+ issue types in our system. However there's only ~7 commonly used combinations for these situations. We would like to present the Support staff with a short list of options. Once selected, kick off the normal Move process (to handle complexities like changes to fields, workflows, etc.)
Thanks for the background on your goals with the workflow, and this lines up with something I have been working on in a test site recently trying to figure out a native option as a workaround to this. It still needs some polishing but is a good starting point to get you going.
A little background, historically this is something that has been blocked by a few different long running feature request, but an option opened up recently specifically for service desk projects where you could do this with the native Service desk automation rules, and you can now create an issue based on action in the service desk project, Noting the Service desk automation rules will get very complex very fast to do the necessary update operations notes on this below. But while you are checking this out Let me know if you have any Questions on this as I know its a huge wall of text, and a lot of steps, and there is a lot of room for improvement based on individual use cases, but it’s a good basic approach.
First, as an initial reference point and background on the feature, details on configuring Automation rules can be seen here:
Beyond Automation rules there are third party apps to extend the functionality further, and have options to do this as well with scripted actions to accomplish this, and my have more simplified methods for this particular task and I would recommend looking at a fe of the apps to see if they would work for your process.
For the add-on apps you could use something like Automation for Jira, or Add Issue on Transition for Jira Cloud, or ScriptRunner for Jira, as an exe of some apps that would give you additional options for this, but check out the Marketplace apps I linked and the related apps section as there are a lot of options if you go this route, and you can check the documentation for each to see if it fits your needs better than the native options.
Back to the native functionality a big point I want to stress is that the logic can get pretty complex on simple actions when trying to trigger automation in two projects that are reliant on cross project actions because of the order in which the action is completed to when the issue is created/updated and then indexed. Because of this there is a lot of potential for logic conflicts with automated tasks as you will need them to fire in very specific orders so that action one in project 1 triggers the follow up action in project 2 which in turn triggers another follow up action in project 1 etc.... . As an exe if you have two two automation rules on the issues creation where one created an issue in project 2 and the other transitions the issue in project 1, and tried to have an "on linked issues transition" in project 2 that triggered a follow up action there would be a conflict as the transition portion could not be seen by issue 2 as it is in the process of being created when issue one is transitioning and the automation action will be missed.
So the following example is an ultra simplified version of how to set this up, but still gets complex fast so I recommend setting up some test projects to play around with, per your specific requirements before applying any changes to the production projects.
So my simplified outline of the approach using the native automation functionality would be as follows:
The Collection Project “DeskTato” creates and maps issues in the Destination Project “Potato Desk” using a unique identifier in the form of a type “Select list (single choice)” custom field value to create the desired issuetype/request type in the destination project.
At this point, you can get as complex as you would like, adding in several fields to work out the necessary logic for the 20+ projects and 30+ issue types you noted, I am sure there will be some necessary trial and error to work out the logic, like which destination project, differences in issue types in the projects, needed field types for required fields on the various projects, etc... noting the more fields or projects given as an option the more complex the automation rules will become, and I am looking to expand Multilevel cascading fields into this process for version 2 as described here “Jira Service Desk: How do I create a conditional field?“ but I’m still working out some of the logic there, but I think this is worth investigating on your end as well because it would be really useful for the 20/30 issuetype/projects that your trying to combine to help narrow the scope of the input options.
Again In my example automation rules I am using one field for the choice to route to one new project and splitting the issue in the Unique identifier into alternate request types on the destination project:
Now if you Create an issue in the data collection portal, a new issue is created in the Working Project with the different request type per the Custom Field selection in the first portal.
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