Do issues created during automations trigger other automations?

[Franz Maruna]

I think the answer is no (perhaps by design, or a bug.)

Problem I'm solving: 
We have times where we need to make a ticket for EVERYONE in the organization. Think "its time to update Chrome for a security issue." We'd like to be able to make a single ticket, hit a button, and get a dozen subtickets made under it - one for each person in the organization so we can track who has done the task. 

I've been able to make an automation that does, ALMOST all of this. I setup a dedicated "everyone" field. I have a watcher looking to see if it's checked. When it changes to Yes, the automation goes through and creates sub tasks for every individual. I'm able to inherit all of the fields like description and due date, but there's no way to inherit status that i can see from this create sub task action. 

Meanwhile, I've made a separate automation that watches for all tasks being created. If the issuetype=sub-task, it looks to the parent and inherits the workflow status field. 

What happens now is when i check the everyone box, all the sub tasks are made, they're assigned to the right people, have the due-dates, etc... But they're all set to incomming... When i look at the audit trail for the automation for assigning status, it hasn't been tripped at all. 

Meanwhile if I manually make a subtask on the same parent issue, it DOES inherit the subtask status... 

So:
1) Is it by design that tasks created during an automation don't trigger other automations or did I find a known bug/feature improvement on the way?

2) Anyone have any clever work arounds so we don't have to still go through each of these sub tasks and flip them to the to-do status?

[Bill Sheboy]

Hi @Franz Maruna 

I believe you are seeing a few effects... 

First thing, the execution order of the automation rules is not predictable.  So consider the triggers and when things could happen.

Next, rules can trigger other rules, but when you want a rule to be triggerable by another (such as transitioning to change status after creation), set the option in the rule details: Allow rule trigger.  Code Barrel (now part of Atlassian) put that in as a braking mechanism to help prevent run-away rule cycling.  They already appear to have other logic to prevent cycle looping.

For your questions, I believe that you could, in one rule:

• Create your sub-tasks,
• Re-fetch the parent issue to refresh its data, and
• Branch on the sub-tasks to use the transition action to change their status

Best regards,

Bill