How to wait for an action to complete before progressing?

[Sam Prince]

I have an action to clone issues from one project to another when they move into a specific column. We use this to allow us to have a "triage" project and have a small group of people decide whether requests are rejected or taken forward and if they are taken forward where to route them.

For the most part this works well, but if a person is assigned to one of the issues in the first project, when the Jira automation tries to clone the ticket the automation fails, saying that it can't assign the issue to that person in the second project (presumably because they aren't a member of that second project):

Clone issue
Error creating issue
User 'theirusernamehere' cannot be assigned issues. (assignee)

Adding them to the second project isn't really a good option for us, so I added an action at the top of the automation to unassign the ticket before it does the clone. That action is carried out without error, but the automation still fails with the same error when it reaches the clone step. When I look at the original issue it has been unassigned so it looks to me like a race condition where the unassigning is happening too slowly.

Is my assumption correct? If so, is there any way to force the automation steps to happen in series rather than running in parallel or failing that introduce a long wait before the clone?

[Bill Sheboy · Accepted solution]

Hi @Sam Prince -- Welcome to the Atlassian Community!

If you are doing the un-assignment followed by the clone in the same rule, the problem is the clone is still using the state/data of the trigger issue at rule load time, and not after the edit.  The fix for this is to use a re-fetch action to reload the data before the clone.  For example:

• ...
• action: edit issue to clear assignee
• action: re-fetch
• action: clone issue
• ...

Kind regards,
Bill

[Sam Prince]

Thanks @Bill Sheboy,  that certainly explains why I saw the behaviour I did. It's useful to understand the underlying model and the fix is very straightforward to implement.

[Bill Sheboy]

Hi, Sam.

I am glad to learn that helped.  For future reference, the next most likely cause of this symptom is confusion over what {{issue}} means at different points in a rule...as context is important.

For example in this rule where issue ABC-123 has a parent of ABC-456

• trigger: some trigger...from issue ABC-123
• ... at this point, both {{issue}} and {{triggerIssue}} refer to ABC-123
• branch: on parent epic
  • ...at this point, {{issue}} refers to ABC-456 and {{triggerIssue}} refers to ABC-123
• ... at this point, both {{issue}} and {{triggerIssue}} refer to ABC-123

And so actions like Clone Issue could have different behaviors/errors based on what {{issue}} is.

Such cases are a good reason to post an image of your rule and audit log with questions; they provide lots of context.

Kind regards,
Bill

[Mark Segall · Accepted solution]

Hi @Sam Prince and welcome to the community!

In your clone action, try adding the assignee field and hard setting it to "Unassigned"

[Sam Prince]

Thanks for the quick reply Mark - I've given that a go and will test it shortly.