Have multiple triggers for a single flow in jira automation

[Omer Meshar]

We are using automation quite a lot, and we have a few scenarios where we want to do something specific (same flow) but have different triggers for it.
These triggers include events and scheduled runs, and can be different from one to the other in:

• The timing (when to do it)
• The filter (JQL - which set of issues to do it on)

We currently have a few copies of the same automation rule, each one with a different trigger, and we were wondering if it wouldn't be better to have a single flow (conditions and actions) that can be used in multiple rules or even better, in a single rule with multiple triggering mechanisms.

[Bill Sheboy · Accepted solution]

Hi @Omer Meshar 

As @Marc -Devoteam- describes, there is no automation rule trigger to cover both scheduled and work item events.  There is a multiple-event trigger, and in my opinion I recommend never using that one due to racetrack timing problems, possible multiple triggering defects, unknown side effects, etc.

Without seeing the specifics of your rules and the scenarios, I recommend pausing to understand the problem being solved by the rules...and thus decide if some of them can be combined in ways to eliminate any duplication.

For specific workarounds to reduce rule / logic duplication, those tend to be complicated.  For example:

1. First, start with the above recommendation to analyze the rules to look for commonality and merging opportunities
2. Use a bunch of rules with different triggers, and have them all "call" a common rule with an Incoming Webhook trigger using the Send Web Request action 
3. Build an external service endpoint, host that, and have the rules call that directly with Send Web Request action 
4. Investigate when a custom Forge application could create a rule action to do what is needed

Regardless of the approach used, combining rules may lead to unintended consequences: more complexity, more difficult maintenance, rule processing side effects, difficultly in detecting and solving problems from overlaps, unnecessary permission granting, etc.  Please consider discussing this with your peer Product Admins to help understand the risk / rewards involved.

Kind regards,
Bill

[Omer Meshar]

Thanks Bill.
I would argue that starting to use webhooks and web requests, or external service endpoint, is a more complicated solution to my problem.

Instead, how about having a 'flow' (conditions and actions) that can be used in multiple rules. I don't mind that the 'flow' will be copied from one rule to another, as long as I can update it in a single place, and then either it is updated automatically in any rule that uses it, or alternatively, I can copy it myself and paste it in the relevant rules. Today, I don't have a way to copy a part of a rule, I can only copy the whole rule, and change its trigger, but that means, that every time I do a change, I will lose the history of that rule, I will need to rewrite the name/description, I will need to configure the trigger and make sure I don't have any mistakes there... that's where my pain is.

So again, I don't mind having multiple rules, as long as I can update them in a quick way, without human errors.

[Bill Sheboy]

Hi @Omer Meshar 

I understand your point.  From my perspective, one person's "complicated" solution is another's simple one, another's hack, etc.

As a reminder, this is the Atlassian Community, and most of the people answering questions (such as myself) are just other customers.  We have limited impact / information about changes to automation rule features which Atlassian plans.  When you want the Atlassian team's direct input, paid license customers may contact them through Atlassian Support: https://support.atlassian.com/contact/#/  Perhaps ping them to learn their thoughts on this topic of reuse.

I do understand your point about having a saved, common set of rule steps to allow reuse.  That feature does not exist in rules today.  Neither does the ability to copy-and-paste the equivalent of snippets within the rule editor (outside the scope of one rule).  The closest thing to that behavior is very carefully updating the exported rule's JSON and then importing it as new, or using the new REST API endpoints to modify a rule directly, updating the steps from a common source.

Kind regards,
Bill

[Marc -Devoteam-]

Hi @Omer Meshar 

This not an option, an automation can only have a single trigger.

[Marc -Devoteam-]

Hi @Omer Meshar 

Please accept my answer as a solution, if my answer helped to solve or provide a workaround to your request.

This will help other community member trying to solve the same or provide them with a work around

P.S. If the answer is very valuable to you, please share some kudos.

[Omer Meshar]

Hi @Marc -Devoteam- your answer did not really help, as I knew there is no such option, and I wanted to hear others thoughts on this.