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.