Is it possible to manage global automations via API?

Question

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:

* Manually edit each global rule in the UI

* 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

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

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

* 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.

Bill Sheboy · Answer

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

Christian Gonzalez_5ti788 · Answer

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.

Trudy P Claspill · Answer

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?