Trigger Priority and Order

[Osama Al-Areky]

I have a booking board processes with five columns representing the different stages (To-do, checkin, customer journey, checkout, done). Each customer is an epic, and tasks are either-to-do or done. I want to automate the management of the board. 

I would like to include two automations to my board. The first, when the epic is transitioned from the to-do status to the checkin status, child tasks are created automatically on the To-do column. Then when all these child tasks are done and transitioned from to-do status to done, the epic transitions automatically to thecustomer journey status. Once it is transitioned to the new status, new child tasks are created automatically again and when these new child tasks are done and transitioned from the to-do status to done status, the epic transitions directly to the checkout status.

The problem I am facing now is about the trigger. Unforunately as far as my knowledge, the trigger options are limited. So, i had to choose issue transitioned as the trigger for both actions (creating of tasks and transitioning of Epic). But the problem is that there is no possibility to order triggers (which one happens first) when they are the same trigger for both actions, and the second problem is that if I try to dinsguish between the two triggers using a condition, for example I used the condition to check if the tasks are done, then execute the second action, otherwise no. But the problem is that with this condition the trigger considers the previous done tasks, so it executes the actions, even though the new tasks are not yet done. 

[Jack Brickey]

Hi @Osama Al-Areky , for the epic transition rule I would use an if/else block - if epic status is checkin then create your 'checkin tasks' else if epic status is "customer journey" then create your 'customer journey tasks', etc. when you create these tasks add a label to distinguish them, e.g. "checkin-task', and 'journey-task'. This will allow you to interrogate the task in your task, transition rule. I don't think you need to worry about ordering your rules since you can accomplish this using a condition to interrogate which status your epic is in.

if this makes sense, give it a try and come back here with some screenshots if you get stuck.

[Bill Sheboy]

Hi @Osama Al-Areky 

Adding to Jack's answer...

The key to doing this in one rule (and so eliminate the timing problems) is the tasks created for each stage (i.e., status) of the epic parent need to be identifiable for a specific stage.  Doing that with a label, custom field, summary, etc. will make finding them and checking their status easier.

And...as you essentially are implementing a state machine with rules, I recommend thoroughly testing this to ensure your rule conditions are both correct and listed in the correct order in the rule.

Kind regards,
Bill

[Bert Dombrecht]

Hi @Osama Al-Areky ,

I believe you can achieve this with three Automation rules.

First, you'll need two simple rules to create your epic children:

---

1. Create children if your epic moves to CHECKIN

Trigger: Issue transitioned
From TO DO to CHECKIN

Condition: Issue Type equals Epic

Action: Create new Task(s) (with Epic Link = {{issue}})

---

2. Create children if your epic moves to CUSTOMER JOURNEY
(This one will be triggered automatically if the epic is transitioned after the first set of children are all completed)

A copy of the first one with From CHECKIN to CUSTOMER JOURNEY in the trigger.

Note: you need to check the box that allows this rule to be triggered by another rule.

---

3. Transition the parent Epic on two occasions

1. IF the epic status is CHECKIN and all children are DONE
-> transition epic to CUSTOMER JOURNEY

2. ELSE IF the epic status is CUSTOMER JOURNEY and all children are DONE
-> transition epic to CHECKOUT

---

In the example below (statuses replaced by RESOLVED, DONE):

Trigger: a Task transitioning to DONE

IF the parent epic status = CHECKIN

• For the parent epic:
  • Check if all children are in status DONE
    • Transition to CUSTOMER JOURNEY

ELSE IF the parent epic status = CUSTOMER JOURNEY

• For the parent epic:
  • Check if all children are in status DONE
    • Transition to CHECKOUT

[Osama Al-Areky]

Thank you but i didn't understand how you did the trigger as a task and then you did the condition on an epic without using branching. i don't have this option. I need to create a branch if I want to do a condition on a issue other han the trigger issue.  

[Bert Dombrecht]

I used the 'Related issues condition' for this.

Then selected the Epic as related issue and added a matching JQL (status = Checkin).

In this way you can add and IF and an ELSE in the same rule.
You could also split this into two rules and add the status condition in the 'For: Epic' branch.

[Osama Al-Areky]

Thank you, 

I tried it but the problem, the actions are not executed on the parent (the Epic). Any action I add on any issue other than the trigger issue, it is not excuted. Even when I used related conditions. 

[Bert Dombrecht]

That should be taken care of by the branch 'For: Epic (parent)' you see in the first screenshot.

Select Branch rule / related issues

Select Epic (parent) as type of related issue.

Any actions triggered in this branch will apply to the Epic (parent) of the trigger issue.

[Osama Al-Areky]

This is what I did. I added the transition action to the branch for the Epic. But it is not executed when the trigger happens.  

[Bert Dombrecht]

You need to choose 'Epic (parent)' instead of 'Parent' for the branch.

'Parent' typically refers to a Sub-task Parent in Jira.

[Bill Sheboy]

Hi @Bert Dombrecht 

An FYI regarding your note:

'Parent' typically refers to a Sub-task Parent in Jira.

With the change to sunset many of the Epic fields and use the parent field for most parent/child relationships, a branch on parent, rather than Epic (parent) could refer to either:

• an Epic (from a Story / Task / Bug) or
• a Story / Task / Bug (from a Subtask). 

The context within the rule and issue type will determine the behavior.

Kind regards,
Bill

[Bert Dombrecht]

Hi @Bill Sheboy ,

Thanks for your note.
It did trigger me to test this more thoroughly. Here are the results:

I set up my initial rule (with branch 'Epic (parent)'). 
-> The test was successful.

Then I copied the rule, replaced the branch selection with 'Parent' and disabled the original rule. 
-> No actions were performed.

So I must conclude that the 'Parent' relation does not target the parent epic in the Automation.

---

Epic (parent)

Automation rule Audit log:
DEMO-210 found and transitioned.

Epic issue history:
Epic transitioned by Automation rule.

---

Parent

Automation rule Audit log:
No related issue found, no actions performed.

Epic issue history:
No change on the epic.