Is it possible to manage global automations via API?

[Christian Gonzalez]

We’re running Jira Cloud with a number of global automation rules (defined under System → Global automation). These global rules all share the same logic, but are scoped to different projects. Today, any time we need to update the logic (for example, tweak a JQL filter or change an action), we must:

1. Manually edit each global rule in the UI

2. Or export all of them, delete the old ones, and import a revised template multiple times

This is both error-prone and time-consuming.

Questions

1. Does the Automation API support global (site-level) rules?

2. If so, what endpoint and payload do I use to list/update/delete a global rule?

3. If not, is there any recommended workaround for programmatically versioning or templating global rules?

Any pointers to documentation or example scripts would be hugely appreciated!
Thanks in advance.

[Trudy Claspill]

Hello @Christian Gonzalez 

Welcome to the Atlassian community.

Can you provide more information about these rules?

You said they are "global" because they come up in Global Automations. Global Automations simply gives you access to all automation rules regardless of their project scope. That page will show you rules that have their Project Scope set to Global, Multiple Projects, and single Projects. The actual scope of each rule is shown in the Scope column on that page.

You said the rules are scoped to different projects but share logic. Can you provide more information about what is being shared between the rules. Are they identical in all ways other than the Project Scope specified in the Rule Details page?

If they are truly and completely identical with the only difference being the Project Scope on the Rule Details page, then you could (potentially) simplify your efforts by having one rule and setting the Project Scope of that rule to Multiple Projects, and then specifying each of the projects to which that rule should apply.

With regard to using an API to update the rules, yes that can be done. The API is documented here:

https://developer.atlassian.com/cloud/automation/rest/intro/#about

You would use this endpoint to update the rule:

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

As noted in the documentation the payload for that endpoint is the same content as the Response of the Get Rule endpoint.

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

All of that still requires that you have some method to identify what needs to be changed, what the change needs to be, and to which rules it needs to be applied. The API doesn't really provide anything to help with those aspects of the task because there is no "search and replace" endpoint.

I am interested to see what other community members provide as suggestions.

[Christian Gonzalez]

Hi Trudy,

Thanks so much for your detailed reply — really appreciate you taking the time!

I see now that I misunderstood how the “Global Automations” section works. I assumed that since I created the rules there, they existed only at the global level — so thank you for clarifying that!

To answer your question:
Yes, these rules are identical in structure. Each one runs on a schedule, checks for any unreleased versions from the previous month, and automatically releases them if all issues are completed. The only difference between them is which project they target.

I did try using a single rule scoped to multiple projects, but I ran into an incompatibility error that prevented the versions from being released correctly. To get around that, I split the rule into one per project, which has worked more reliably so far.

This is my first post, so I'm not sure what the guidelines are about sharing rules, but if you'd think it be helpful I'd be happy to share it after cleaning it.

Thanks again for pointing me to the right documentation — this really helps! I'll try and get this working in the meantime

[Trudy Claspill]

If you can share an image showing all the components of one of the rules that would be helpful to us to understand the flow and advise you if it is possible to reduce the number of rules that you have.

If you can't paste an image of the rule, describing it in text would be helpful. What actions/conditions/branches are you using to find the unreleased versions?

It may also depend on the Types of the projects. Release Versions applies to Software projects. Are you using these rules against both Company Managed and Team Managed projects?

[Christian Gonzalez]

Thanks Trudy, 

All the automations are set on software company managed projects.

What this automation does:

When it runs:

The rule is triggered on a schedule , once a month, on the first Monday at 9:00 AM CST.

What it does:

It checks for unreleased fix versions from the previous month for each release type on a project (Database Changes, Model Updates, Platform Upgrades).

How it works:

Condition Blocks (If blocks):

Each If block checks whether the version exists and whether the issues inside meet certain status conditions:

If all issues are either “Done”, “Closed (Released)”, “Executed”

Or no issues are present.

This ensures that only completed work gets released.

Lookup Issues:

If the conditions are met, the rule looks up issues in the version and pulls the most recent resolution date. 

It then releases the fix version automatically and sets the release date to the most recent issue’s resolution date found above.

It overrides the release date if one already exists.

Repeat for each type:

There’s one If block for Database Changes, one for Model Updates, and one for Platform Upgrades, each follows the same pattern.

[Bill Sheboy]

Hi @Christian Gonzalez 

I suggest building those version names for the conditions, etc. one time and saving them with Create Variable for reuse.  That will reduce the risk of typos / errors from the repetition.

Kind regards,
Bill