Automation script picking up incorrect issue type

[Nilesh Thali]

We have an automation script containing a large number of rules that we downloaded from one jira cloud instance and ran in another one (they are both on different domains and we could not use cloud-cloud transfer).

What we noticed is that the rules are incorrectly set up in the new instance.

for example, we have one that says when a Risk has occurred create an Issue work type, but on the target instance, the rule says Create a Milestone work type.

Any ideas why this might be happening?

[Trudy Claspill · Accepted solution]

Hello @Nilesh Thali 

This can happen when you import rules from a different instance.

Automation rules may record the IDs of the things you referenced rather than the names. So while your rule may reference an work type named "Risk" within the rule code it recorded the ID for that work type (i.e. 10101). When you import the rule in the destination system it will then reference the work type that corresponds to ID 10101. This can happen with other elements also such as custom fields referenced in Edit actions and statuses referenced in Transition actions.

Even if you have the same work item types in both systems, they may have been created in a different order in each system which would result in them having different IDs.

You can review the XML of the rules export to identify items referenced by ID. You can fix the XML to match your destination system. You could then re-import it which would make a new copy of each rule. You might want to delete the rules you already imported.

Or you can review each rule in the destination system UI looking for discrepancies and fix each one.

[Bill Sheboy]

Hi @Nilesh Thali 

Yes, and...to what @Trudy Claspill described about the types:

Depending upon the space / project type, one may need to open the rule in the editor and re-select the types, values, etc. to change them and republish the rule.  In other cases, the rule gets "glitched" and requires reselecting the rule scope, then removing the trigger / action / condition / branch and re-adding it to the rule to ensure the correct scope is used for the typing and values selection. 

Worse still: connections stored in rules (e.g., to Confluence, Slack, etc.) are completely broken by such migrations and they usually only get fixed by recreating the rule from scratch.

I truly wish there was an easier way to do this type of cross-site, space, etc. rule migration.  Perhaps something more like the work item "Move" menu action, where a guided wizard asks specific questions about scope, type, value, and connection changes to help ensure success.

Kind regards,
Bill

[Mikael Sandberg]

Does the project in the new instance have the same work item types as in the original instance? Based on your description it doesn't sounds like that so the automation picked up the first work item that is available in that space in order to save the automation without any errors.