Creating a rule that will run other rules

[Gregory Machin]

Hi, 

New to Jira autmation & rules. 

I want to create rules that I can reuse, by calling these from a "parent" rule. but I can't seem to find any good explanations / examples. 

I can see how to create a "child" rule without a trigger, or which is the correct trigger, as I only want the child rule to run when called by the parent rule. 

How does one call a child rule from the parent I can't see which action to use. 

Thank you 

Greg

[Ste Wright]

Hi @Gregory Machin 

There isn't a trigger which "calls" another automation rule, but you could set the Parent Rule to make a unique modification on an Issue (eg. add Label, etc), which is the Trigger for the Child Rule to activate (eg. Field Value Changed Trigger).

To allow one rule to activate another - you also need to set this in the Rule Details section - ensure the checkbox "Allow rule trigger", "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 checked / TRUE.

---

Could you provide some more detail in relation to this need if you'd like more specific instructions on how to set up these rules?

• What does the parent rule do?
• What does the child rule do?
• When should the parent rule call the child rule?

Ste

[Gregory Machin]

Thank you Stephen for responding. 

The rule I have to remediated is triggered when a new issue is created, based on the content of the description, new tasks are created and linked to the initial issue, there as a fair amount of logic and actions in the current rule and it has hit the 65 limit.  My intention was to break it down into child rules, a rule for each type of task, eg tasks intended for Service Desk would all be under one rule, and all tasks for networks would be under another rule. 

• What does the parent rule do?
  would be triggered on new issue, with logic to determine the required tasks that need to be creates. 
• What does the child rule do?
  The child rule will do the work of creating the task or tasks based on the requirements. 
• When should the parent rule call the child rule?
  When the appropriate logic has been triggered. 

Your thoughts ?

[Ste Wright]

Hi @Gregory Machin 

Could you provide some specific details about the rule and how the Tasks are generated from the Parent, and linked back to it?

It doesn't need to be the whole rule, just a sample of it :)

To use separate rules, you'd need a method for the "Child Rule" to identify the parent and link back to it. Is there a unique parameter on each parent Issue that could be used for this?

Ste

[Gregory Machin]

Hi @Ste Wright  

I figured out using labels and triggers to call trigger a child rule, it is achieving the desired result for now.

[David Leal]

@Ste Wright It is not clear to me the Allow rule trigger option. If I have a rule that is triggered on issue creation updating a field and another rule that is triggered when the same field gets updated, both rules are executed, even if I don't have this option marked. I checked that both rules were executed at the same time and the field was updated twice. Both trigger conditions are satisfied which is why both are executed. I don't know if marking that option forces a specific order of the rule execution. In my case, both were executed exactly at the same time, so I don't know which one went first. Looking at the issue history it doesn't inform which action correspond to which rule, it just indicates the field was updated twice, but not the rule who did it.

What is the difference then?

Thanks

[Ste Wright]

Hi @David Leal 

I've seen it most often used to let rules be sequenced.

What trigger are you using for the field value change? If it's Field Value Changed, it can be set to run based on "Create Issue" (or "All Operations") - so effectively your two rules are running in parallel, rather than sequential, as there's two triggers which are based on creation at that point.

Ste

[David Leal]

@Ste Wright That is what I suspect the Allow rule trigger forces the rule to be executed sequentially. The first one is on issue creation (rule 1), where the field is updated. Here is the rule 1:

As you can see Bug Application/Product field is assigned, but also in the second rule (rule 2):

The same field is updated. For this rule, the trigger condition is for any change and for any issue operation:

so both trigger condition applies to issue creation, so both are executed on any other.

Now if rule 2 I mark the option: Allow rule trigger, then rule 2 can be executed in response to rule 1, so I can remove the Edit issue field for the Bug Application/Product field in rule 1 since rule 2 will be in charge of that. I updated both rules.

Looking at the Bug history (sorted by older first) both rules are executed and Bug Application/Product field gets populated, but I am not sure about the sequencing. According to the history of the action in the Bug (in case it sorts the entries properly because the tracking time is the same).

It looks rule 2 goes before rule 1 because Bug Application/Product was updated first.

Then I realized I have a third rule (rule 3) that is triggered on Bug creation too. This rule assigns the Product field value and also Components, Fix version, etc. from its corresponding epic. The value of the Product field is used to set the field Bug Application/Product on rule 2, but in the history, it doesn't appear the Product field was assigned (to Data Core) even though it was used to set the value of Bug Application/Product field with the correct value. Here is rule 3:

Researching more, rule 2, is executed twice: I would say after rule 3 and rule 1 (both on creation), but it is just reflected once in the history because the field Bug Application/Product is updated just once:

Maybe it is a complex scenario to follow, the fields get updated as I expected, but the order of execution is not expected. 

Maybe the sequencing is correct, but the history doesn't reflect the proper order, still a mystery why setting the Product field doesn't appear in this history of the Bug and why rule 2 seems to be executed first.

Thanks for any help,

David

[Ste Wright]

Hi @David Leal 

I feel like it'd be best to review your rules, it feels like they're conflicting with each other.

For Rule 2, I think you'd also need to edit the "For" section of the trigger to not include "Create Issue", otherwise it still won't be reacting to the "Allow rule trigger", it'll be running in parallel with Rules 1 and 3.

Ste

[David Leal]

Thanks, @Ste Wright I thought about that too about rule 2, but I want to populate the field Bug Application/Product on Bug creation. If I remove this in the "For" section, then I am not sure if the field gets populated, on Bug creation.

Anyway, I don't know why the Bug history doesn't show the Product field has been updated through rule 3. Thanks anyway for your help. I made some minor modifications and created two Bugs (but keeping the "For" section for the rule section for Creation and issue updates), and Bug Application/Product gets populated from the initial steps. 

[PARISATO Marie-Hélène]

En somme à quoi sert de cocher "Autoriser le déclenchement de la règle" ? 

[Sérgio Baixo]

One approach to use is to have an action in rule 1 that writes a comment, and then another rule (rule 2) that is automatically triggered when that comment is written. Then, inside rule 2, you just delete that comment and continue to execute the rule