Moving issue via automation

[NoName]

What is the best way to move a ticket via automation within the same project, when both the Issue and Request Type are different? If X conditions are met on the form, the ticket needs to move. The Issue Type always updates fine but then errors out on changing the Request Type. I can't seem to get it working, I assume it's primarily because I can't make the rule run in a specific order and have the Issue Type change first, then Request Type.

[Lacy Saute · Accepted solution]

Hello! Have you tried adding a re-fetch action after the action that changes the issue type? If you configure the rule to edit the issue type, then re-fetch the work item data, then edit the request type, that should resolve the issue.

[NoName]

But I can't make the re-fetch rule run specifically after changing the Issue Type, right? Since I can't tell the rule what order to run in? If the re-fetch can happen at any point in here, it can happen before the Issue Type changes, which is pointless.

[Lacy Saute]

It runs in top-down order. So the way you have it configured in this screenshot should work.

[NoName]

Ok, support has told me you can't choose the order that the items run in the rule and anything in the branch could run first. Are you saying this is incorrect?

[Trudy Claspill]

Hello @NoName 

Can you provide a screen image that shows your entire rule?

If the rule you have shown in your response to @Lacy Saute is generating an error, what error are you getting? Please provide screen images that show all the details in the rule Audit Log for the rule execution. Make sure to fully expand each entry within the rule execution log entry so we can see all the details.

It is generally not advisable to change issue types using the Edit action unless the issue types are configured to use the same workflow, field configuration, etc. Otherwise there may be requirements of the destination issue type that are not getting met.

[NoName]

No, I had not added the re-fetch item until Lacy mentioned it because I had been previously told by support that you cannot choose the order the items run in any one branch and they can run in any random order. So I assumed the re-fetch would be useless since it may or may not run after the Issue Type changes. I have set up every automation rule with the knowledge that the items may process in any random order so if what they told me was incorrect, this drastically changes how we setup our rules. 

[Trudy Claspill]

 Without seeing the entire conversation you had with Atlassian Support I can't really address what they said.

But I suspect they may have been referring to this:

In the automation, parallel execution of the branches (to main thread) can produce incorrect/unexpected outcome 

The steps within the branch will run sequentially.

The branch as a whole unit may run in parallel to other steps in the automation that are on the same main line.

[NoName]

It's been quite awhile since we did the setup and it was one of the first rules I did so I don't have the conversation but it stemmed from an issue I had where it was a relatively simple rule.

If X, then do A, B, C, D, in that order, one single main line, no branches, no if/else. 

C/D was happening before A/B occasionally, which would cause the rule to error out because they require A and B to be set correctly first.

When I couldn't figure out why, I opened with support and they said you can't dictate the order that things run in in automation, so just assume that all steps will run simultaneously every time. This is why it works sometimes and other times do not because sometimes it processes it in the order I wanted.

I've set up our entire automation system (several hundred rules) based on this but if you're saying things should be running sequentially in each line/branch, this opens up a new world of possibilities for us. I have many complicated and more rules than we need just because I was always under the impression that you cannot get it to run sequentially.

I will test with the re-fetch and adjust some other rules if this does work.

[Trudy Claspill]

Steps should run sequentially within the branch. Steps should run sequentially in the main line except for the branches, based on the kb article I linked.

If you found that was not the case, I can't address what Atlassian may have said.

If you find it is not the case for some rule now, we would need to dive into the specifics of the rule and the results of its execution.

[NoName]

I understand you cannot speak to what they said. I'm just trying to explain my thought process and why I did not do the re-fetch before. And I do understand about the branches potentially running simultaneously with the main line but I thought it would only make sense for the line itself to be sequential. Thank you for confirming this and as I said, this drastically improves my quality of life with this being the case.

If I run into other errors after making the changes, I will come back. I appreciate this tidbit of information.

[Joseph Chung Yin]

@NoName -

I agreed with Lacy's response.  Can you provide a bit more information of the following -

Issue type A associated with Request Type X

Issue type B associated with Request Type Z

So, if the FORM conditions met - you want the rule to switch Issue Type A (Request Type X) into Issue Type B (Request Type Z)?

I look forward to your response.

Best, Joseph Chung Yin

[NoName]

Yes, if specific criteria is met in the form, the issue needs to get moved to a different issue and request type.

[Vitalii Rybka]

I have a hunch the issue comes from changing both the Issue Type and Request Type at once – try updating the Issue Type first, then use a Re-fetch action, and only after that change the Request Type, or split it into two separate rules.