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; } } }

Trigger a second rule after first rule completes

Kazumi Kerr

Hello,

I created 3 automation rules because there were over 100 steps and needed to split into multiple rules. I'm trying to figure out how to trigger a second rule after the first rule completes. Similarly, how to trigger a third rule after the second rule completes.

In a rule detail, I checked the "Allow rule trigger" option.

However, I believe I need to have some kind of conditions to specify "the rule 2 starts after rule 1 completes". Does anyone know how to solve this?

Accepted answers

Mykenna Cepek

My first thought would be to define a custom field to support triggering for rule chaining.

One such field could support all projects in an organization, as long as you controlled the field content across all your rules.

The "Field value changed" trigger will then focus on changes to that field for later rules in the chain. For a rule configured for a single project, this should not trigger excessively.

For the content of this field, I might suggest a GUID. That way you don't have to maintain a list of them (to avoid collisions with other rules using the field).

How would this work? After creating the custom field in your instance and configuring your project(s) to access it, you'd do the following to chain Rule A to Rule B:

Generate a new GUID (there are plenty of online GUID generators).
At the end of Rule A, set your custom field to have the GUID value.
Trigger Rule B on the custom field changing, and use a conditional immediately to confirm that the custom field value matches this GUID.

Rule B should, of course, use the checkbox to enable other rules to trigger it.

NOTE: If your custom field is scalar (holds a single value), then ensure each project only has a single rule chain. If you want to support multiple rule chains in a single project, a bit more complexity is required:

Create the custom field as Standard type "Labels", which allows for multiple values.
Rule A should ADD the GUID to the custom field.
Rule B should REMOVE the GUID from the custom field (after detecting a match).

Would be interested to know if this solution works for you!

All comments

Mykenna Cepek

My first thought would be to define a custom field to support triggering for rule chaining.

One such field could support all projects in an organization, as long as you controlled the field content across all your rules.

The "Field value changed" trigger will then focus on changes to that field for later rules in the chain. For a rule configured for a single project, this should not trigger excessively.

For the content of this field, I might suggest a GUID. That way you don't have to maintain a list of them (to avoid collisions with other rules using the field).

How would this work? After creating the custom field in your instance and configuring your project(s) to access it, you'd do the following to chain Rule A to Rule B:

Generate a new GUID (there are plenty of online GUID generators).
At the end of Rule A, set your custom field to have the GUID value.
Trigger Rule B on the custom field changing, and use a conditional immediately to confirm that the custom field value matches this GUID.

Rule B should, of course, use the checkbox to enable other rules to trigger it.

Create the custom field as Standard type "Labels", which allows for multiple values.
Rule A should ADD the GUID to the custom field.
Rule B should REMOVE the GUID from the custom field (after detecting a match).

Would be interested to know if this solution works for you!

Bill Sheboy

Hi @Kazumi Kerr -- Welcome to the Atlassian Community!

You are describing splitting down a rule with over 100 steps, and then triggering those rules sequentially.

I wonder if all of the steps you note are one atomic operation, or if there could be separate rules triggered on changes made...or even better, utilize the looping operations from advanced branching to help make a smaller rule. And perhaps some process analysis would reveal other simplifications to the rule (e.g. combined condition testing).

Given the limitations in the rule editor and error handling, smaller rules would be easier to maintain and improve.

Kind regards,
Bill

Kazumi Kerr

@Bill Sheboy

Thank you for your suggestions. I agree that smaller rules would be easier to maintain and improve.

The rules I try to make is to crate a list of tasks/subtasks for each project. So, I would like to perform the rule 1 --> rule 2 --> rule 3 in order.

Kazumi Kerr

@Mykenna Cepek

Thank you for your suggestions. I understand theoretically, but I'm not sure how to execute it due to my lack of experience in Jira automation.

I created sample rules: "RULE 1" and "RULE 2". However, when I tried to create a project, only the Rule 1 was executed. I'm sure my syntax in Rule 2 condition is incorrect.

Screen Shot 2021-11-04 at 5.58.12 PM.png

Screen Shot 2021-11-04 at 6.02.36 PM.png image (1).png

Kazumi Kerr

@Bill Sheboy & @Mykenna Cepek ,

It worked!

I created a sequential rule by looking at the {{issue.summary}} and it successfully made tasks in order.

Thank you for your help! Screen Shot 2021-12-05 at 7.57.40 PM.png Screen Shot 2021-12-05 at 7.56.05 PM.png

Welcome!

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

Quick Links

Unanswered
Groups
Help

Find more posts tagged with

automation