Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Trigger a second rule after first rule completes


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.trigger.png

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?

2 answers

1 accepted

2 votes
Answer accepted
Mykenna Cepek
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
Nov 02, 2021

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!

@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.pngimage (1).png

@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.pngScreen Shot 2021-12-05 at 7.56.05 PM.png

2 votes
Bill Sheboy
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
Nov 02, 2021

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 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.

Suggest an answer

Log in or Sign up to answer
AUG Leaders

Atlassian Community Events