Rule orchestration - allow switch between parallel and sequential execution of Automation Rules

Problem Definition

Currently, Automation rules are executed in parallel, which prevents the user to get the benefits of a sequential execution, where he could trigger, for example, multiple Workflow post functions to have the expected result of the first post function be used for the second rule being triggered.

Suggested Solution

Provide the user the possibility to choose whether he wants the parallel or sequential order for the Automation rules execution
This could also be extended for not just the THEN clause of the Automations, but also for all automation rules using the same trigger, for example.

***

Ability to control concurrency for a rule / force a rule to run serially (rather than rule branch order being non-deterministic), e.g. to allow issues created on a related issues branch to be actionable in another related issues action

**

Currently for performance reasons, as soon as a rule branches, the items for that branch are added to the automation queue, and there's no guarantees around ordering.

In some cases this is problematic, for example, when a later branch is trying to update an issue with values set by an earlier branch.

Update: 06/07/2018 - Branches with a single branch (Current, parent, jql with 1 result) will now run inline and hence execute in order.

Related ask: Ability to control concurrency of a set of rules - Sometimes, rules are configured to work that has issues when ran simultaneously, or out of order (e.g. rules that trigger off the same source issue). It’d be useful to be able to group these rules and then force them to run in order

Trigger transition of a specific subtask based on other subtask transition

For example:

• A.1 If Subtask 1 is Closed then transit subtask 2 from "to do" to "started"
• A.2 If Subtask 2 is Closed then transit subtask 3 from "to do" to "started"
• ... and so on.
• A.3 If last subtask is Closed then transit Parent from "XYZ" to "To Global Review"

Our related issue branch should allow you to select next subtask as an option.

Issues created on a related issues branch should be actionable in another related issues action

Consider this rule:

• Trigger: Manual (triggered on a sub-task)
• Action: Related issues action 'for parent' issue
  • Action: Create another sub-task in the same parent as the trigger sub-task
• Action: Related issues action 'Created' issues
  • Action: Transition that sub-task we just created

Currently the second related issues branch will not see the sub-task created by the first related issues branch. This is due to performance issues and scheduling, where the actions on the first branch get put back on the automation events queue and will run after the second related issues action tries to look for 'created issues'.

This is tricky to fix. For now the workaround is to create a second automation rule that is allowed to be triggered by another automation rule and listens for 'create issue' from the first rule.

To fix this properly we'll either have to allow multiple levels of related issues branches (so you can add a 'created issues' related branch in the first related issues branch), or introduce some kind of delayed execution, where the second related issues action will wait until all actions on the first branch have finished.

Some rules are really low priority batch jobs that we don't care about and should not hold up anything else. Would be great to mark low priority rules somehow in rule details to ensure they always run with very low priority.

Workaround

Utilize multiple Rules to enforce a sequential processing of Actions:

• How to create dynamic looping in Automation for Jira

Note that normally Branches within Automation Rules do not get counted as their own Executions, but implementing the workaround in the above article will mean each iteration will be its own Execution. In addition, be mindful of the Automation Service Limits when considering if this workaround is right for a given situation.