jira software and jira service managment

[Kamil Askerov]

how to make syncronisation between jira software and jira service manager optimal way?

I have about 20 projects jira software(JS) and jira service managment(JSM). They have same workflows  and same statuses.

                  1 Project JS = 1 Project JSM,

                  2 Project JS = 2 Project JSM,

                  ...

                  20 Project JS = 20 Project JSM.   

but all statuses not same in 1 , 2 , 3. 1 and 2 workflows and statuses different like in others. 

How to make automation of sinchronisation statuses. When Customer changed status in JSM it must automaticaly changed in JS. (Status names are same). I can write about 50 automation for statuses (its about 50 statuses there) but its not optimal. 

[Mark Segall]

Hi @Kamil Askerov - Syncing statuses between JSM and JS is a common scenario I run into.  I typically go through the following process before I create any automation:

1. Where can I establish normalization of statuses?  For example, work with all teams to ensure alignment on core statuses (e.g. everyone uses "OPEN" as their created status and everyone uses "CLOSED" as their resolved status and "IN PROGRESS" as the primary "working status").  Getting alignment solves for automation simplicity.
2. What statuses really need to be sync'd? It's easy to fall down the rabbit hole and want to sync every status. However, in most cases, the JSM agents/customers really only care what status category the corresponding Jira Software is in.  An approach I've often used is that instead of copying various statuses from the JS project to JSM, I'll have an automation that triggers when the issue has been added to sprint that populates the sprint end date into a date field on the JSM issue so that agents/customers have a general sense of when the issue will be complete coupled with a simple sync rule to inform that the work is not started, in progress, or resolved.

This may or may not work for your environment, but it's my approach to handle such matters and ultimately results in no more than 3 straight forward automation rules.  The toughest part of it is the change management around getting teams to normalize on those key statuses.