Automation to transition the parent to Closed or Done based on the status of a specific subtask

[Brandon]

I have a team-managed project used by my operations staff to manage repetitive tasks.

• The project has only tasks and subtasks
• Every task has five subtasks
• The five subtasks that are created and attached to the parent are the same every time (e.g., assume that each of the five are named Subtask1, Subtask2, etc., so every task has a Subtask1, Subtask2, etc)

This project has two possible 'done' statuses, "Done" and "Closed". The deciding factor hinges on Subtask3- a task should only be allowed to transition to "Done" if Subtask3 is also "Done". If Subtask3 is any other status, and a user tries to transition the task to "Done", I want to instead transition it to "Closed" (or just prevent it from moving to "Done"). 

For context, we transition the parent to done manually. For some reason, some people on my staff continue to choose the wrong status. I realize this may not seem like a big deal, but many other things are happening (e.g., automation, reporting, etc) that depend on the parent being routed to Done or Closed correctly.

To summarize what I'm looking for:

WHEN: task is transitioned to DONE or CLOSED

IF the subtask named Subtask3 = DONE

THEN task is transitioned to DONE

ELSE task is transitioned to CLOSED

If the above isn't possible, then a rule to prevent a transition to DONE IF the subtask named Subtask3 is not DONE. Basically, the task would remain in the status it was in before a user tried to transition it to done.

[Jack Brickey · Accepted solution]

Hi Brandon,

The first thing to note is that automations happens after an event. So it can't prevent an event from happening. It can undo and change the event. Such as, let's assume that we can figure out how to analyze the status of subtask3, then we could change the status of the task from Done to Closed. The challenging piece is to figure out which subtask is subtask three. There has to be some way to analyze this within automation. So, what is unique about subtask3 and can we always rely on this footprint for that subtask?

[Brandon]

Good point, and great question.

For starters, Subtask3 is always the third of five subtasks created. I have an automation rule that creates the subtasks for each new task, and as far as I can tell, the order in which the subtasks are created is exactly as I have it set up in the automation. In other words, Subtask1 is always first, Subtask2 is always second, etc.

Subtask3 is the name/summary/title of the subtask every time it is created. Task1 has a Subtask3, as does Task2 and so on. 

If the name/summary and/or the position of Subtask3 (3rd of 5) aren't sufficient to base the rule on, I suppose I can add something unique to it to make identifying it easier. For instance, a specific label or some other field value that isn't used elsewhere in the project.

[Brandon]

I suppose I could also create a link between Subtask3 and the parent in the subtask creation rule. It seems redundant to me since Subtask3 already has a parent/child relationship, but if it's necessary to be able to run the automation reliably, then so be it.

Or maybe set an entity/property variable? I haven't worked with those yet, but if it's a method of assigning a unique value to the subtask that can be used to reliably identify it that could work too.

[Jack Brickey]

Hi @Brandon , stewing on this and came up with a thought...

What if you were to create a rule like this...

• trigger - issue transitioned
• condition - type = subtask and Summary ~ "Subtask 3" and status = done
• action - edit issue, field labels = "ST3-Done"

second rule for the task action...

• trigger - issue transitioned
• If/else condition - status = done and labels = "ST3-Done"
• then add comment "ok Task to Done"
• else transition task to Closed

The above is a complete solution, but hopefully you get the idea and agreed that it might work and give it a go. If you do, let me know what you come up with. An interesting used case for sure. Might be worth an article in the community once we get it working and refined.

[Brandon]

Hey @Jack Brickey , sorry for the delay, I try to stay away from work over the weekend.

Yes, you're solution should indeed work. Based on your earlier response I had already concluded that for this to work I would likely need to set some field to a unique value (e.g., a label) in order to properly identify the subtask and route the transition.

I likely won't be able to modify and test the rule until tomorrow, but I will report back as soon as I have the results.

[Brandon]

Hey @Jack Brickey 

I created two automation rules using your idea as an outline. What I came up with is slightly different but the concept is similar. In any case, I tested this automation and they worked flawlessly. I really appreciate the help!

To recap the solution that I ended up with for future readers:

1. I needed a way to be able to reliably identify that a specific subtask had been completed. In my case, it was "Subtask3" (for the purpose of this example, Subtask3 is the actual name/title/summary of the subtask
2. When Subtask3 is transitioned to done, we add the label "ST3-DONE" to it

So now I can reliably apply a unique label to a specific subtask when it is completed. This is vital to the next automation rule, which is for the parent task.

1. My project has two "Done" status categories- Done and Closed. In my use case they mean something different, which is why it's important that the task end up in the correct status
2. When a task transitions to either Done or Closed then we check to see if one of its subtasks has the label "ST3-DONE"
3. If the label is present, then we transition the task to Done. This is the status it should be in when Subtask3 has been completed
4. If the label is not present, we transition the task to Closed