Auto transitioning sub-tasks in teams managed space

derek.imrie

I'm having issues getting some automation to work. I have a workflow that will create 4 sub-tasks moving the status from open to submitted. If i need to move the status back from submitted, I want any of the sub-tasks that are still open to be moved to a status called cancelled.

The automation triggers and the it sees the subtasks but it states that the sub-tasks "did not match the condition". I have tried to update the branch to match JQL with status = "awaiting approval" instead of sub tasks present. Again it will find he sub-tasks when I validate the query but the automation won't transition the sub-tasks to cancelled

There is a transition from awaiting approval to cancelled as per the work flow below. Moving the sub-tasks manually from awaiting approval to cancelled also has no issues.

Automation Criteria

Audit Log

tasks still open

Main workflow

Sub-Task Workflow

Narek Pirumyan

Hi @derek.imrie,

Your audit log shows the cause. You have the “If sub-tasks present” condition twice: once before the branch and once inside it.

• Outside the branch, the condition runs against the issue that triggered the rule, SAR-91. It passes, since SAR-91 has sub-tasks.
• Inside the branch, the rule is working on each sub-task (SAR-92, 93, 94, 95), not on SAR-91. The condition now asks whether each sub-task has sub-tasks of its own. They don’t, so they all show as “did not match the condition”, and the Transition action never runs.

Fix: delete the second “If sub-tasks present” condition from inside the branch. The branch (“For: Sub-tasks”) already selects the sub-tasks, so it needs no check that they exist. The structure should be:

1. Trigger: Work item transitioned (to Open)
   If sub-tasks present in thetrigger (to avoid additionnal condition component)
2. Branch: For Sub-tasks
   Issue fields condition: Status = Awaiting approval, if you need only open sub-tasks to be cancelled
3. Transition the work item to Cancelled

Anything inside a branch is evaluated against the branched issues, not the one that triggered the rule. If you need the parent’s data there, use the smart value {{triggerIssue}}.

Let me know if it works this way.

Regards,
Narek