nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Automation rule to sync status between Service management and Software dev projects

Ionut Nita

Hello,

We have two projects MAFSI which is a Software development type project and AFSIM which is a Service desk type project. We have an automation rule that clones tickets from AFSIM -> MAFSI every time a new tichet is created, the tickets are linked between with clones/is cloned by:

We created an automation rule to sync all available statuses between the two projects:

The rule runs with success when we change status Open -> In progress (from project tickets) and when changing Waiting for customer -> Open (from service desk portal):

The rule fails with errors when changing status to the remaining combinations:

Can you please help us fix this rule to work for all available statuses.

Best case scenario is to have one global rule that syncs all statuses for both projects. Second best case scenario is to have one rule that syncs statuses AFSIM -> MAFSI and one rule that syncs statuses MAFSI -> AFSIM.

Thank you for any suggestions/feedback!

P.S our sync status rule is created based on the answer provided here:https://community.atlassian.com/t5/Jira-Software-questions/Jira-automation-sync-different-statuses/qaq-p/2507953

But for step 3 we didn't find the filed where to add the value {{statusTable.get(triggerIssue.status)}}

Accepted answers

Walter Buggenhout

Hi @Ionut Nita and welcome to the Community!

I think the fact that the transitions have worked in some cases are pure luck instead of related to the configuration of your automation rule. The way you have set up your rule right now, you are indeed not using the status mapping table you have created.

The {{statusTable.get(triggerIssue.status)}} you should fill out in the last step, where you have now selected copy from trigger issue. Instead of copying the transition, you should actually SET the value and fill in the smart value there.

On a side note: I have not used this technique in practice myself. But if you start seeing errors after you make this adjustment, make sure that the statuses in your workflow actually match with what you put in the mapping table. I would not be surprised if they are not called AFSIM - In Progress etc.

Hope this helps!

All comments

Walter Buggenhout

Hi @Ionut Nita and welcome to the Community!

Hope this helps!

Dick

Hi,
I'm not a fan of keeping a double administration in a single database. Isn't there a way to avoid this whole synchronization agony by using a single project with i.e. a well-defined component to discern whether something is MAFSI or AFSIM or both?

Ionut Nita

Hi @Walter Buggenhout I managed to add {{statusTable.get(triggerIssue.status)}} in the last step as you mentioned but after this change the rule does not work for any of the statuses, not even the Open -> In Progress/ Waiting for customer -> Open which worked before.

Now we are getting errors like these:

Could it be an issue that one project uses two workflows and one projects uses one workflow?

Service desk uses one workflow for all issue types (Incident, Question, Sub task)

Software project uses two workflows, Incident and Question is identical with Service desk. Sub task workflow is different.

Thank you,

Ionut

Ionut Nita

Hi Dick,

Due to multiple reasons including license costs and business logic we are forced to use this setup Service desk - Software dev.

Dick

best go with the ID's of the statuses.

you can get the ID of statuses if you perform an issue search and start the query with:

status =

In the popup list beneath you see the status names and their cf_xxxx values. Use those to copy over values between your two types of project.

Walter Buggenhout

I think it's important to do 2 (or maybe even 3) things here:

Ask yourself if you really need to create a software ticket for every request that comes into your service desk. While it is quite normal to use different tools for those 2 areas, I am quite sure that not every ticket that comes in really requires effort from your dev team. If it does, and you are choosing this setup for licensing reasons, then maybe you should simplify the workflow of your JSM tickets into e.g. New / With Development / Done. If certain tickets can be handled by your service team (without involvement from dev), you may want to redesign the workflow so In progress is something for your service team only and With Development may represent the handover to the software team.
Consider if you really need to duplicate all transitions. In the scenarios I described under (1.), you would only need to create a software issue when you send a ticket to that team (and not automatically whenever a ticket gets created) and sync the status back from the software ticket to JSM when you complete the software ticket. That would only be 1 update, drastically simplifying your scenario.
No matter what scenario you implement, the status you try to move an issue into with an automation rule, must be available from the status the issue is currently in. Looking at the subtask workflow you shared, an issue that is currently in status Open cannot be transitioned to Completed, because there is no transition between these statuses.

So, I would recommend to go back to the drawing board first to design exactly what you want to happen. Then, with that up your sleeve, implement this step by step. If you get an error, look at the issues the audit log mentions as impacted and have a close look at their current status, the status you're trying to get it into and see if that is a valid transition. That should explain a lot.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

cloud

jira-service-management-cloud

jira-service-management