Automatic rule to transition Epic Status based on a Task's transitioned Status

[Kathryn Swearingen]

Hi all, 

Our Jira issues are structured like this: 

Epic -- User Story -- Tasks

There's (typically) 1 Epic per release. We use 1 User Story per 1 webpage that we're updating, then we do 1 Task per each stakeholder (ex: developer, QA, UAT; story points are recorded here). 

Most of our projects have a User Story (1) and Tasks (2; 1 for dev, 1 for QA) dedicated to Build Kit Assessment as the first User Story to be triggered. Therefore, we'd like to write an automatic rule that when the developer-specific Task is transitioned to In Progress then automatically transition the Epic to In Progress and update its Start Date field. 

We use Manual Trigger automation to create the User Story from the Epic (so the User Story is a child of the Epic). Then from the User Story we use Manual Trigger to create the dev-specific Task and a QA-specific task for assessing the build kit. We don't use Subtask.

I've written this rule, but it just won't work. I've ensured that the User Story and 2 Tasks have the same Epic Link. I have an automatic rule in place that successfully transitions the User Story to In Progress and updates its Start Date, but I just can't get that Epic to do the same. 

HELP!?!?!? :-) 

[Rahul Ingle]

I want to create new automation, if Epic status done and someone link story to epic. in this case EPIC need to go In Progress status.

I have create new automation rule for the same but not achieve. sharing automation rule steps below. can you please help for this issue.

1)

When: Issue linked
Types: All link types
2)
If:Some Linked Issue match
Types:All link types Match issuetype = Epic AND status=Done and project-Test
3)
Then:Transition the issue to In Progress
Thanks
Rahul

[Bill Sheboy]

Hi @Rahul Ingle 

I recommend creating a new question, and perhaps linked back to this thread.  Otherwise only the people following this older thread will see it.

When you create your question, please post images of your complete rule and the audit log details showing the rule execution.  Those will provide context for the community to offer suggestions.  Thanks!

Kind regards,
Bill

[Bill Sheboy]

Hi @Kathryn Swearingen 

As you are connecting the Task as a child of the Epic (like your User Story is also), have you tried changing the to: Branch to Parent (Epic)?  That would ensure the Task goes to the correct Epic.

If you have tried that and it did not work, would you please post an image of the audit log details, showing a rule execution that did not process as expected?  That may provide context for what is happening.  Thanks!

Kind regards,
Bill

[Kathryn Swearingen]

Oh, thanks for reminding me. I forgot to mention that I've tried the Epic (parent) option; even tried the Issues in Sprint option. None worked. 

Here's a screenshot from audit log: 

Here's a snapshot from the actual Epic of how issues are linked to it: 

I have 1 label specific to Build Kit assessment on both the dev-specific task and the User Story that the 2 tasks link to.  I do have an automatic rule in place that transitions the linked User Story to In Progress when its linked DEV Task transitions to In Progress (and populates the Start Date of the User Story), which is working as expected.

This WoW is challenging in terms of getting Jira linking to link correctly, since Subtasks are more ideal. I also want to write a rule that will automatically close a User Story once all Task links that link to the User Story are marked as Done. If we were using Subtasks this would be easy (I did it as a proof of concept; worked like a charm) but since we use Tasks I'm not quite getting the logic correct. Frustrating, because I think I'm very close and it's probably a case of looking at it too much and missing the obvious.

[Bill Sheboy]

This is curious...Are you using a team-managed or company-managed project type?

Let's try an FYI and an experiment.

First, the FYI: When you have one rule that could lead to another rule executing, the second (downstream) rule needs to have the "Allow Rule Trigger" option enabled in the rule details.  This option is disabled by default to prevent mistakes and run-away rule execution.

You note one rule moves the Task to "in progress" and the other rule to updates the Epic;  if the "Allow Rule Trigger" is disabled that second rule will not run.

Next, the experiment.  Let's try a very simple test rule as that branch should work.

• trigger: manual
• condition: issue type is Task
• branch: on parent (Epic)
  • action: write to the log...
    • the parent key is {{issue.key}} for the triggered issue key {{triggerIssue.key}}

Then run that rule for your dev Task to confirm the correct parent shows.  If it does, there is something happening in the other conditions to cause the symptom.  If it does not, then the issues are not acting as if they are linked, parent/child.

[Kathryn Swearingen]

Thank you for the FYI, I had definitely missed that, so will update on all applicable rules I've written. 

As for the experiment, here you go: 

[Bill Sheboy]

Thanks, Kathryn!

Next I suggest trying the branch to epic again, and post your rule and the audit log results...after you enable those "Allow Rule Trigger" options where they are needed.

By the way...for a rule like this that could cause some "churn" in a team's project, it can help to use a test project to build/test the rule, and then ask your site admin to copy the rule to the "production" project for final testing.

[Kathryn Swearingen]

Yup! I just did that -- change back to Parent (Epic) and now it works! Checked the Audit Log and its there. 

I'll definitely look into the Test project thing. Thank you so much for your help! 

Now I'm on to the next rule -- close the User Story when all linked Tasks are Done; am currently stuck on that :-( 

[Bill Sheboy]

Well done!

There are a few examples in the community for that next rule.  It is quite similar to what you have done, although it has some edge cases.

• trigger: transitioned to Done
• condition: issue type is Task
• branch: on JQL to a linked issue (of your desired type) which is a User Story
  • condition: check the User Story is not already in "Done"
  • action: lookup issues with JQL for the sibling Tasks linked to the story
  • advanced compare condition: check if all of the lookup issues are done
  • action: transition the story to "Done"

[Kathryn Swearingen]

Thank you for those steps! I've written this rule (found something to base the JQL off of since I'm not good at JQL). The Audit Log shows Success but when I look at the details it seems to run through hundreds of Tasks, so I'm off somewhere -- I got tripped up at the advanced compare condition and how to write that. Where am I off? Does the advance compare condition happen in the branch, or back out? 

[Bill Sheboy]

Well...the JQL for that branch needs to be more specific to narrow things down...Otherwise it will try to yank in every story!  Let's narrow that down to linkedIssues to the trigger issue which are stories:

issue IN linkedIssues({{triggerIssue.key}}) AND issueType = Story

Next for the advanced compare condition on the lookup...You are checking if there are any non-done issues, so...

• for the Lookup Issues, the JQL would be 
  • project = myProjectName AND issue IN linkedIssues({{issue.key}}, "is blocked by" AND status NOT IN (Done)
• and for the advanced compare condition check if the count is zero...
  • first value: {{lookupIssues.size|0}}
  • condition: equals
  • second value: 0

[Kathryn Swearingen]

Updated the rule to this, but it's still yanking in all User Stories and it's closing the User Story before all linked Tasks are marked Done.

Also, we do have one other Status value that's considered "end state", which is "LIVE (Launched)" so I've added that in because the rule was changing User Stories in Live (Launched) to Done, which we don't want. 

Also note that I've checked the box for "Check to allow other rule actions to trigger this rule. Only enable this if you need this rule to execute in response to another rule.". Is that correct?

[Bill Sheboy]

Please note I was suggesting to change the JQL for the branch and for the lookup issues.  It seems you did not change them as I suggested, so please try that from my last comment.  

To be clear, the JQL for the branch could be:

issue IN linkedIssues({{triggerIssue.key}})
 AND issueType = Story

And the JQL for the lookup issues could be:

project = OSP
 AND issue IN linkedIssues({{issue.key}}, "is blocked by")
 AND status NOT IN (Done, "LIVE (Launched)")

Also, there appear to be two lookup issues action in your rule, and you only need one for this use case, using the above JQL.

Regarding the option "Allow Rule Trigger": only enable that for a rule when you expect changes from one rule could trigger another.  For example, if any rules can transition a Task to "done" you could enable the option for this rule.

As a tip, automation rules can take work to get correct...while under development that can break a lot of things quickly  :^)  So it is a good idea to create rules in a test project (or even a free test Jira instance) until they are working as expected, and then copy them over to your "production" projects.

[Kathryn Swearingen]

Apologies for my last rule; I think I was brain fried when I put it together. 

I do have a sandbox to test in and using your latest rules it now works like a charm. Thank you very much!!!! 

[Bill Sheboy]

Awesome!  Are there other open things for this one, or do you want to mark this question as "answered"?  Doing so may help others with similar questions find solutions faster.  Thanks!

[Kathryn Swearingen]

Nothing else open. Question is definitely answered. Thank you!