I would like a way to save Automation snippets as common methods.

[#1]

As a longtime Jira administrator who's been using Automation since it was a plugin, I find the tool a wonderful and necessary addition. It allows me to add quality-of-life tweaks for my users and address headaches that Atlassian either lacks the capacity or the will to handle themselves. However, with great power comes greater complexity: each time I add something useful for my team, someone else gets a great idea for a similar but slightly different approach. The end result is many Automation rules that are almost the same, with just enough variations to justify keeping them separate.

Managing these rules becomes difficult, especially if something changes that affects the underlying logic. For example, Microsoft changed the method by which we are allowed to send messages from Jira to Teams. This forced me to update all Automation rules that previously used a simple webhook to instead talk to Power Automate. Now, they've changed the URL structure for all of Power Automate, so I have to update all of these rules again.

There is no easy way to keep track of which rules are reaching out to which Power Automate flows; sure, we can filter by specific nodes in Automation, but that doesn't go deep enough. Our team has addressed our needs by manually building a database in Confluence with all of our Automation rules and the various details that are relevant to us. I wish this was something native, because it's a lot of overhead to maintain it. Also, Atlassian decided to update their own URL structure, so all of the embedded links in our database are wrong now.

A solution that I would like to see—which would make it easier to find and update similar rules—would be the implementation of a library of common methods in our Automation. For example, if I have three Teams channels that I want to send messages to from Jira, I could have three methods in Automation, named for the specific Teams channel, that I could call from an Automation rule. These methods would essentially be a rule snippet that contains the URL, authentication, etc. required to send a message somewhere common. Then it would be simple enough to attribute all Automation rules that use that method so they could be filtered out and adjusted; ideally, the method itself could be adjusted and thus all related rules would be fixed at once.

I know what some will say: just make a new rule with only that section and call it via web request. I've done this, it works, but this increases the number of Automation rules required per action and also slows down the whole process. I want the methods to function as if they are natively part of the main Automation, just easier to maintain.

What do you guys think? Have you figured out better ways to keep track of similar functionality across rules? I would love to hear ideas that require less maintenance than a custom database.

[Alan Bruce]

I have had a little success using the labels. Not quite what you are looking for but has been handy when going thru 200+ automations

[Brock Jolet]

@Alan Bruce we also use labels to group rules that are part of a collection or theme, it does help but after adding a few too many labels it becomes noise. We have also defined a common naming convention so that we can look at a rule and know what space it belongs to and what is the trigger action.

[Shawn Stevens]

Imagine inheriting Atlassian Administration from another Admin with no documentation and reasoning behind the automations. I like your idea of documenting the automations in Confluence Database. I do like the idea of a common block that could be shared with multiple automations. 

We are also terrible at documenting things at my company.

Side question for you. Do you allow project administrators to create automations as it sounds like you are mainly controlling the creation of these automations (Global or project specific). I would love to turn over some of the automation responsibilities to the project admins per project, how does that figure into your plan to have shared blocks. 

[Josh McManus]

I'm also very interested in solutions to this issue. One thing that I think is a particularly complicating factor is that Automation Rules can't be shared between projects unless you're a Jira Administrator. I would love it if I could create highly-refined rules that Project Administrators could browse and choose to enable for their projects, and the ability to select Project Automation rules and "Bless" them to become available to browse. I know this doesn't *quite* solve the same problem you mention above, but it does seem like a possible solution to aligning the organization around certain best-practice automation rulesets that are specifically relevant to our organization.

[Brock Jolet]

@Shawn Stevens We have two primary site admins, myself and one other person, who handle most of the Automation stuff. Space admins sometimes add their own rules that are specific to their needs, but this is exceedingly rare. When we add rules to our Confluence database, we tag them so it's simple enough to then find anything new without that tag. Our space admins tend not to follow our naming conventions and such, so we'll go back after them and clean up whatever they made.

[Carolyn White]

At first I thought this was another of my own emails to leadership pleading that we get this under control. It's a similar issue with Workflows - since everyone can do their own thing, there are a gazillion near perfect replicas of the same thing, just one small thing different. How we got around that may also work for this scenario. I met with several groups of people, looked at the raw data through the Power BI connector to extract raw data (don't get me started on what you will discover by doing that!) and created 3 workflows that everyone could choose from. When a new project starts, I meet with them and they make choices from a buffet line. They choose from one of the 3 workflows and then they choose their automations. Some automations are assigned for everyone.

Do shared workflows and automations prevent random one-offs? Yup. Then we have a committee to discuss those one-off proposed changes so the requestor can weigh in and it is tested for residual impact before the change is made. Freedom is a good thing, but even highways have speed limits and boundaries.

Since we report from raw data, we can do some deep dive reporting that Jira can't, but the anomalies throw things off.

[Shawn Stevens]

You will probably laugh, but at the moment we give temporary access to select individuals so they can create and test the automations that they need, because normally the know what they are looking to do and me having to interpret those would lead to an inefficient process for my team. 

So we give temporary access to create/edit automations, which I don't necessarily like to do. We also currently have the ability for project admins to create project automations, turned off because most of our projects have 5 - 20 admins and I didn't want all of those folks creating automations with no guidelines. 

I need a better approach and standard when it comes to automations because I would really like to turn this over to the Project admins and then make them responsible for fixing them when the they break or fail. 

I still like having a block of common functions that could be shared, because to your point, there are a lot with similar setup with slight variations. 

[Darryl Lee]

Hey @Brock Jolet I don't have a solution for management. Your database sounds like a great idea, but yeah, managing that manually does not sound fun. If Atlassian ever implemented Automation/API support, I think there would be opportunity to tie in with something I wrote a while ago:

• Hacking/Parsing Automation Rules with JSON for Fun and Profit 

The reason I bring that up is that while it won't help you manage/more easily address a problem like of "Microsoft changed the method by which we are allowed to send messages from Jira to Teams", parsing the JSON (and maybe writing it into a Database?) will let you identify which rules will need to be fixed, which is... something?

For instance. I recently learned that Atlassian recently made {{baseurl}} a reserved Smart Value in Confluence (where previously it was a Jira-only thing), which broke one of my Automations.

I realized I had probably used that Smart Value in other rules, and so I exported the rules and just searched through them for that Smart Value. It was not optimal because I didn't parse each rule and its definition out separately, but in retrospect, I probably could've done that with jq without too much pain.

Anyways, my point is, don't forget the rules can be exported as JSON and so there are some things you can do with that data.

I've actually used Stiltsoft's Table from JSON macro from their Table Filter, Charts & Spreadsheets for Confluence to automatically generate a listing of rules that includes Name, Description, Executions!, State, Created, Updated, and Author.

Ideally it would also let us add comments. I guess I could try switching it to a Database created by a CSV import, but ugh, it'd be a pain to maintain comments across the manual syncs. C'mon Atlassian, let's make Databases actually _useful_.

[Bill Sheboy]

Hi @Brock Jolet 

Short answer: in my opinion, the Atlassian team would need to decide to support better rule management, documentation, and "snippet" reuse before this improves for customers at all license levels.

Your solution of "snippets" by using the Send Web Request action to "call" an Incoming Webhook trigger rule with the reused rule components / steps is a frequently observed one. Although it can run into challenges with scoping and API tokens for the client rules, Atlassian outages, etc., and be difficult for end-users to know what is happening behind the curtain of the called rule.  (Tip: I recently discovered the token itself can be from a smart value in the header, making this a bit more configurable in reuse scenarios wanting to limit permissions / scope.)

Another approach uses standardized, global or multiple-project scope rules. This one seems to make sense in enterprises keeping a firm handle on automation rule usage, and / or who use more-rigidly defined value stream processes.  And, the approach became more cost-effective after the packaging model changes to usage counts by product rather than by global / project scoping.

Neither approach easily helps with change management of automation rules...although workarounds could be rule-copying / sprawl, repeated exports / backups, documentation, etc.

For any reuse approach, documentation is key...which is where some of the larger problems fall.  The recent general release of the REST API endpoints to manage rules help, but only slightly as it can take several steps to gather all of the rules and document them (e.g., in Confluence).  Those wanting to be a bit meta, and use another rule to document all of the rules find that is not truly possible / sustainable.  There are no publicly available events for rule create / update, there are no bulk rule or audit log endpoints, and the elephant in the room: the ever-shifting landscape of automation "improvements".

Last year, I wrote my own rule parser, editor, documenter, and executor outside the built-in one.  Several others have described doing this to parse rule JSON for documentation purposes, and thus they are familiar with the component nesting; component identifier inconsistencies, particularly across different products (e.g., Jira versus Confluence automation); and, identifying which fields are accessed or impacted by a set of rules.  Several times in recent memory, Atlassian has added dozens of new actions at one time!  Thus, customers need to actively monitor their rule-extracted documentation to find things not yet described by Atlassian so the customer may update their own automation "decoder ring".

My hope is Atlassian will recognize automation rules for what they are: valuable, customer enterprise code which needs effective tooling to manage it.

Kind regards,
Bill

[Aaron Geister]

With Rovo-Dev, I believe your opportunity will be present to support snippets or something if you are willing to learn to use Forge with Rovo-dev to help you build your own add-on function. 

I would think this would help you actually get results by making your own product that helps you and maybe could help others. I doubt that this is something Atlassian will build now that they gave you the power to build it. Do need to be a developer to do this but it helps if you have some experience.

If you haven't tried to use Rovo-Dev and Forge you should give it a try. Its been really helpful for me. 

Here is a article that helped me from a Community Champion: https://community.atlassian.com/forums/Rovo-for-Software-Teams-Beta/Rovo-Dev-CLI-with-Forge-MCP-and-Jira-Bitbucket-Integration/ba-p/3143450

Atlassian wiki:
CLI:
https://support.atlassian.com/rovo/docs/install-and-run-rovo-dev-cli-on-your-device/

IDE:
https://support.atlassian.com/rovo/docs/work-with-rovo-dev-in-the-ide/

[Shai Gilboa]

On top of all the good answers above, are you aware that Atlassian finally have API support for automation rules?

https://developer.atlassian.com/cloud/automation/rest/api-group-rule-management/#api-group-rule-management

It's not perfect, but I use it, through python scripts I wrote to export specific or all automation rules, and also create them. I use this to promote rules from sandbox to prod, also for rules changing through phased changes approach (that is to change a rule you create a copy with changes and then switch to that, instead of updating the existing rule). You can however use these APIs to update existing rules as well.

Understanding the automation rules components, triggers, and conditions structure in JSON is a little tricky though not too complex.

(sadly cannot share due to company policy, but can assist in direction)

[Stiltsoft support]

Hi @Darryl Lee ,

The Table Filter, Charts & Spreadsheets for Confluence app is ours and maybe we've got the issue wrong but nevertheless: all our macros are compatible.

So, if you use the Table from JSON macro to recreate tables in Confluence, you can wrap this macro in the Spreadsheet from Table macro and add manual comments right there.

[Josh]

I would love a way to create / provide a library of modular automation solutions / snippets.