nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Is there a way to create an automation that when an epic is deleted all the child tasks are deleted?

Elizabeth_Lee

I previously created an automation that if an Epic was deleted, all the child tasks under that epic would automatically be deleted as well. It seems that sometime after it was created, the rule stopped working as it was intended. Now when the Epic is deleted, the Child tasks as not longer associated to any Epic. I have tried multiple different rules but nothing seems to be working.

This is the previous rule that worked:

I would very much appreciate it the community's help with this one. Thank you.

Accepted answers

John Funk

Hi Elizabeth - Welcome to the Atlassian Community!

So what is happening now? It just deletes the Epic and doesn't touch the children?

Bill Sheboy

Hi @Elizabeth_Lee -- Welcome to the Atlassian Community!

First thing: deleting work items can be problematic as there is no built-in undo feature. It may be better to move an Epic (and its child work items) to "Done" and set the Resolution to a state such as "Abandoned". This prevents accidents and enables recovery of the items. Lots of teams do this, and then disable the delete permission for everyone except Site / Product Admins.

If you still want to delete the work items...

For the rule you show, it was likely a coincidence it worked earlier. The reason is the child work items' Parent field contained the key to the Epic, and when the Epic is deleted, there is a racetrack timing situation where:

an event is raised indicating issue_deleted for the Epic
the Epic is actually deleted
issues referencing the Epic are updated to "unlink" them, including the Parent field and issue links
etc.

But, we do not know the actual order those things happen. And, based upon my observations of other rule triggers with timing problems, it is possible the issue_deleted event is raised before the Epic is completely gone in terms of other work items' references.

One way to safely do what you describe is to reverse the ordering or capturing all the data first, perhaps with a manually triggered rule rather than using the built in Delete feature:

trigger: manual, to run from the Epic, and perhaps adding a user input field to "Are You Sure" confirmation, as described in this article
smart values condition: to check the user input is confirming the deletion
condition: issue type is Epic
action: lookup work items, with JQL, to find all the child work items, and save their keys
action: delete work item (to remove the Epic)
branch: on JQL to the results of the lookup
- action: delete work item, to remove a child

The order of the steps is important to reduce (but not eliminate) possible update collisions. And, I recommend setting the trigger permissions such that only a few people can run this rule.

Kind regards,
Bill

All comments

John Funk

Hi Elizabeth - Welcome to the Atlassian Community!

So what is happening now? It just deletes the Epic and doesn't touch the children?

Bill Sheboy

Hi @Elizabeth_Lee -- Welcome to the Atlassian Community!

If you still want to delete the work items...

an event is raised indicating issue_deleted for the Epic
the Epic is actually deleted
issues referencing the Epic are updated to "unlink" them, including the Parent field and issue links
etc.

One way to safely do what you describe is to reverse the ordering or capturing all the data first, perhaps with a manually triggered rule rather than using the built in Delete feature:

trigger: manual, to run from the Epic, and perhaps adding a user input field to "Are You Sure" confirmation, as described in this article
smart values condition: to check the user input is confirming the deletion
condition: issue type is Epic
action: lookup work items, with JQL, to find all the child work items, and save their keys
action: delete work item (to remove the Epic)
branch: on JQL to the results of the lookup
- action: delete work item, to remove a child

The order of the steps is important to reduce (but not eliminate) possible update collisions. And, I recommend setting the trigger permissions such that only a few people can run this rule.

Kind regards,
Bill

Elizabeth_Lee

Hi John, that is correct. It is deleting the Epic and leaving the Children unassociated. Any help with this would be greatly appreciated. Thank you.

Elizabeth_Lee

Hi @Bill Sheboy, a previous automation was slightly different than this and it was working when it suddenly wasn't working anymore. And yes, we are sure that we want to delete the Children when the Epic is deleted. I am not as well versed with the technical aspects of setting up all these Automations so it will take me some time to figure out your instructions. Once I set it up and try, I will let you know and show you whether it worked or if I'm missing something in the process. I appreciate your response and the help. Thank you.

John Funk

I suggest following Bill's advice as I should have mentioned in my original post that deleting issues/work items is a bad idea. Simply update your workflow to include a status for Canceled or Abandoned or Aborted or whatever you like. Then create your automation rule based on the transition of the Epic to that status.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

cloud

jira-cloud