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

How to Link Automation rule ??

suneel babu

Dear Team,

I have a automation rule, which it has reached the Components limit 65. So, I just want to break it down in two Automations that should trigger one after another . The Question is How we can link those two automation rules.

How we can do that??

Regards
Suneel Babu

Comments

Charlotte Prescott

Depending on what you're trying to achieve. You could just have them be triggered by the same thing but differ in component actions.

Alan Bruce

I do not think this is possible as the Automation rules kick off in random order. This would be nice though to help make sure things happen in a specific order.

Urmo

When i had same 65 Component limit, then i create two sepparate Automation for solution. I use time wait for one automation run, then after later another will run also.

Urmo

Alan Bruce

I suppose you could set a field to a specific value and then have that one trigger the next one. You could use re-fetch for the action to update, etc.

suneel babu

Hi @Urmo ,

Thanks for your response,

Can you pls elaborate a bit, what you have done with this "time wait"

Thanks

Regards,
Suneel Babu

suneel babu

Hi @Alan Bruce ,

It suppose to work,

Otherwise there will be no Use of automations at all & as well as restriction usage of Components <65.

Regards,
Suneel Babu

Stefan Draber_kwaltd

Hi @suneel babu

I think the cleanest thing to do would be to build the second rule with a trigger "Incoming Webhook".

This will provide you with a unique link which triggers the rule to start. Take this link and create a web request on it as the very last action in the first rule. So, last thing to do for rule 1 is to call rule 2.

Does this make sense to you?

Urmo

In Jira Cloud Automation have Delay option to set how much time it should wait before run.

chad.leblanc

I've used Power Automate to create new stories in Jira - not sure if that's the app you're using, but depending on what your process is doing, there may be a small triggering effect there that could fire another flow here, to start another flow simultaneously

Here are some of the available triggers I can see (may differ for everyone)

Davide Giglioli

the last action of your first automation rule should edit a custom field

you trigger the second automation when value change for the custom field

less elegant that webhook

but easier to implement (and to troubleshoot) in my opinion

Madhuri Latha Bhumireddy

Hi Suneel,

Try with Re-fetch issue data.

Thanks

suneel babu

Hey @Davide Giglioli ,

I understand your suggested approach,

But the thing is, we have a form field , which should be copied form field variable from JSM forms to jira (Cloud) by using form ids- Jira Automation rule,

Typically I can say that is not a custom field, which we cannot edit by adding Edit custom field trigger at the end of the 1st rule.

Any suggestions.

Regards,
Suneel Babu.

Dirk Ronsmans

This would be the cleanest solution!

End your first rule with a "send webrequest action" and create a 2nd rule with "incoming webhook" as a trigger.

This way you'll link them together

suneel babu

Hi @Madhuri Latha Bhumireddy ,

The trigger " Re-fetch issue data" ,

Where we have to use in both the rules & How we can set it up ??

Regards,
Suneel babu

Leonard Hussey

Options I've used in the past:

1. When order of steps is mandatory and there is no possibility of splitting steps in two parallel paths: Best / cleaner option is put your extra steps in an incoming webhook automation and call it as last step of your first automation (the "crowded") one

NOTE for #1 Edit a field and have the 2nd automation monitor field edits is also workable. BUT: if you fall into this trend, you'll probably end up using just a handful of fields for this "control" and _many_ automations monitoring those few fields for edits. Think of ping pong ball on mouse traps: huge wave of automations becoming active, checking conditions and most of them not doing anything. I've moved out of this way when Atlassian started counting automation runs vs. a limit.

2. When the steps can be handled in two parallel paths that are _not_ interdependent: two automations that are triggered with the same event.

Something to be careful about is: As other commenters said, automations are triggered in parallel and not always immediately. So, this ends up being a pseudo-random. Even if you closely time it with data reloads or the new Delay action, you still have no control on whether the automation will trigger _immediately_ after the monitored event happens. I've faced "race conditions" due to this uncertaintly.

----

On the other hand, there is sometimes also the possibility to reduce the number of elements. Just this week I came to understand that in an IF condition, each of the checks you do inside counts as an element!! So: and IF block with 3 checks in all-match mode, do count as 3 elements

--> IFs with several conditions are usually easy to optimize. Most times you can exchange several checks (e.g. Field value is X) with a single JQL condition. Just yesterday I faced the 65 limit and reduced to 57 doing this. Note: JQL element in automation says is "slower". I've not faced problems, but your situation might be different.

Finally, if you want to really dig deep and make your life miserable, there is one more option to explore: jira automation smart values logic evaluations. Say you have an IF-ELSE tree with field checks and depending on evaluation you assign a value to a variable to use later. The same can be done by evaluating smart values logic conditions _during_ the variable assignment. This will embed the whole IF-ELSE tree inside the value assignment to the variable and save you several steps. BUT: it gets complicated real fast and this is only really useful when you face that "such a complex IF-THEN-ELSE tree for such a simple topic... I just wasted so many conditions on this..." feeling.

Good luck!!

Bill Sheboy

Hi @suneel babu

First things first: pause to understand why the rule needs 65+ components / steps. Perhaps if you explain what problem your rule is trying to solve, that will help the community to offer better suggestions.

Until we know that (or see your specific rule implementation)...

Longer rules typically fit into several categories:

multiple conditions to handle different paths
a desire to enforce the order of created issues (rather than using branching)
multiple audit log writes to help diagnose / manage rule execution
multiple steps to mitigate racetrack / timing error problems in the automation rule engine
lack of knowledge about some of the newer rule features

You appear to be using Jira Cloud (based on where you posted this). In that case, there are several features which could help manage rule length, subject to your Jira license level and usage limits:

Rather than using multiple conditions, investigate use of Lookup Tables or Conditional Logic to collapse multiple steps into just a few.
Rather than using audit log writes separately, try using the {{#debug}}...{{/}} smart value wrapper to echo rule actions to the log without consuming a rule step.
As others have noted, and for limited cases of fewer than 10 loops, chain rules using the Send Web Request action and the Incoming Webhook trigger
Use separate rules, with the same trigger, and different conditions to manage the separate cases

Kind regards,
Bill

FYI: would one of the community champions / leaders please move this thread from the product area for admins to the Jira product, questions one? Thank you!