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!


Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

Jira Automation rule size

I have one more question on Jira Automation. We everyone's helpful answers, I have been able to get very far along in my project. I ran into the rule size limit. It suggested that I break my rule apart into separate rules. I have no problem with that because it will make their maintenance more manageable.

The question I have is the Best Practices for splitting a rule. Do I create a new rule triggered by the same manual trigger I am using? If so, is there an issue with ordering them or will they run simultaneously?

Or is there a way for one rule to call another rule?


Thanks again for all your help and expertise.

1 answer

1 accepted

1 vote
Answer accepted
Jack Brickey Community Leader Dec 14, 2022

Ho @Don Hames , I thing the answer depends on the details. However, while you cannot have a rule directly invoke another you can do so via the triggers indirectly. For example...

  1. Rule 1 triggers on transition and sets a value in a custom field (CF)
  2. Rule 2 triggers on issue updated with a condition on the CF value

The order that rules are triggered is top to bottom in the list. You can order them via drag and drop.

If you can share details of your rule we might be able to provide more guidance.

Hi @Don Hames 

Yes, what Jack suggests:

Some scenarios requiring longer rules can be restructured with branch loops, list iterators, conditional filters, lookup issues, smaller parent/child rules, etc.  Knowing the problem you are trying to solve and seeing your complete rule may help the community to suggest alternatives.

Kind regards,

Like Jack Brickey likes this

Thank you for your quick replies. Below is a screenshot of the rules that need to be processed from a single manual trigger. I already started breaking it apart. The pink decision symbol s the primary condition; if there are additional, they are the white decision symbols. The rectangles represent an Epic that will be created, and each Epic can have from 1 to n Stories.

My current thinking is to write each line with a pink decision symbol as a separate rule and have it trigger off the same manual trigger they all will use. Do you see any issues or have other suggestions?

rules example.png

Don, what do the rectangles represent in your diagram?  For example, is all of this logic to set the value of one field?  Or is it to take additional actions?

Let's say this was to set the value of one field.  In that case, much of that logic can be combined into a single conditional statement.

Would you please post an image of your rule, as you currently have it?  Thanks!

Hi Bill. The rectangles represent a set of Epics and their associated Stories. When the conditions are met, a new action to create an issue is triggered, and the created issue has the summary and description for the issues being added.


I figured out a way for the first trigger to be fired manually to activate the other rules, and each rule has its own set of conditions that must be met before the Epics and Stories are created. It seems to be working smoothly at the moment. Thanks for the offer to help.

Suggest an answer

Log in or Sign up to answer

Atlassian Community Events