Hello community, I am looking for the best way to automate the integration between Jira Service Management (JSM) and Jira Software, specifically in the following area: Status automation * Is it possible to synchronize statuses between the JSM ticket and the Jira Software issue so they reflect the same progress? Those statuses shown in the image are the ones we have in JSM. Any insights or recommendations would be greatly appreciated. Thank you in advance!

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; } } }

How to Automate the Link Between Jira Service Management and Jira Software? Case 2

Julian Andres Carvajal Bedoya

Hello community,

I am looking for the best way to automate the integration between Jira Service Management (JSM) and Jira Software, specifically in the following area:

Status automation

Is it possible to synchronize statuses between the JSM ticket and the Jira Software issue so they reflect the same progress?

Those statuses shown in the image are the ones we have in JSM.

Any insights or recommendations would be greatly appreciated.

Thank you in advance!

Captura de pantalla 2025-03-31 1100291.png

Accepted answers

Trudy P Claspill

Hello @Julian Andres Carvajal Bedoya

You can trigger rules based on the status of an issue changing. In your rule you can evaluate the status and use that information to make a decision about changing the status of a related issue. There are some questions you would need to answer to determine your implementation.

1. Is the synchronization going to be one-way or two-way? Would you
a. Update only Software issue status based on JSM status change?
b. Update only JSM issue status based on Software issue status change?
c. Update both issue types based on changes in the other?

2. How would Jira know which issues to update?
You would need some method for the rule to determine that if issue ABC-123 has a status change then issue XYZ-456 needs to be updated. One method to do that is to create an issue link between the related JSM and Software issue. The rule can use that link information to find the issue that needs to be updated.

3. How do the status values map to each other between issues? Are you using the exact same status values in both projects or different status value? Are there customizations in the workflows that limit who can execute transitions, requirements that need to be met before a transition can be executed, or validations that need to happen when a transition is executed?

Based on the answers to the above, the Automation rules have the potential to become complex.

Clara Belin-Brosseau_Elevatic

Hi @Julian Andres Carvajal Bedoya

If you want to synchronize statuses between a Jira and a JSM ticket I can suggest trying our app Elements Copy & Sync. You'll be able to map workflows from different projects so that they reflect the same progress as you requested.

Don’t hesitate to try the app for yourself it's super simple to set up and it’s free for 30 days.

All comments

Trudy P Claspill

Hello @Julian Andres Carvajal Bedoya

Based on the answers to the above, the Automation rules have the potential to become complex.

Clara Belin-Brosseau_Elevatic

Hi @Julian Andres Carvajal Bedoya

Don’t hesitate to try the app for yourself it's super simple to set up and it’s free for 30 days.

Julian Andres Carvajal Bedoya

Hi, @Clara Belin-Brosseau_Elements

Thank you very much for the solution! This could definitely be an opportunity worth exploring, and we will take it into consideration.

We appreciate the suggestion and will look into Elements Copy & Sync to see how it aligns with our requirements.

Julian Andres Carvajal Bedoya

Good day Trudy,

Thank you for your approach, it has helped me better define the requirements for this implementation.

1) In this case, the synchronization needs to be bidirectional, following this workflow:

- When a ticket arrives in JSM and the corresponding issue is created in Jira Software, it should be set to Backlog or "To Review"

- When the issue in Jira Software is assigned to a team member and moved to "In Progress," JSM should notify the triggering user that the ticket is now "In Progress"

- Once the development process is completed and the issue is "Deployed to Production" the status in JSM should update to"Resolved" or "Completed"

- If the ticket is canceled in either Jira Software or JSM, the corresponding issue in the other system should also be updated accordingly

2) Could you advise on the most efficient way to establish the link between issues, considering your analysis? I have conducted a few tests with automation rules, but since I am still exploring Atlassian Automation, I haven't yet found the right sequence of actions for proper implementation.

3) In this case, we do not have the same status values configured in JSM and Jira Software since this specific setup applies to support tickets, while JS boards handle both support incidents and new requests/internal adjustments. Given this scenario, what recommendations would you suggest to optimize the process and make the most of the available Jira services?

I sincerely appreciate your time and guidance. Wishing you a great day!

Clara Belin-Brosseau_Elevatic

Great, let me know if you have any question

Trudy P Claspill

Another point to consider.

Would there ever be a case where you use an Automation rule to change the status of one issue, and need that to change the status of the other issue?

If so, one or both rules might need to have this option enabled in the Rule Details.

Screenshot 2025-04-06 at 2.52.53 PM.png

That could lead to an infinite loop in automation rules; i.e.

- JSM rule monitors for change to JSM issue status and updates Software issue status.

- Software rule monitors for changes in Software issue status and updates JSM issue status.

Normally you would want only one of these to run. If the JSM rule executes and causes the Software issue status to be updated. you don't then want the Software rule to run (detecting that automation changed the Software issue status) and try to change the JSM issue status.

But, if you have a third automation rule that could cause one or the other issue's status to change, then you would want the JSM or Software rule to run, to cause the changes in status in the other issue.

But if you enable the option to let the rule detect a change made be another automation rule, then it detects changes made to the Status by any automation rule. Thus potentially entering a loop of automation rule executions.

Welcome!

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

Quick Links

Find more posts tagged with

jira

cloud

jira-cloud