How can I copy automation rules across multiple Jira projects without site admin access?

[Sriram Mishra]

Hi Community,

I'm a Project Admin for multiple Jira projects and have created several automation rules in one of them. I want to reuse or replicate these rules in my other projects, but I’ve encountered a limitation that’s slowing me down.

Here’s the issue:

• I can’t change the scope of an automation rule from one single project to another.
• I also can’t set the scope to “multiple projects”, which would be ideal for rules that are identical across projects.
• I understand that changing the scope (even from one single project to another) requires site admin access, which I don’t have and can’t request due to internal policy.

What I’m trying to achieve:

• For rules that are identical across projects, I’d like to use “multiple project” scope.
• For rules that need minor project-specific changes, I’d like to copy them and assign them to another single project.
• Unfortunately, I can’t do either without site admin rights.

Suggestion:

It would be incredibly helpful if there were a permission model where an admin could be granted access to multiple selected projects (not site-wide), allowing them to manage automation rules across those projects—including changing the scope between them. This would avoid the need for full site admin access while still enabling efficient rule management.

My question:

Is there any workaround, permission configuration, or tool that allows a Project Admin to copy automation rules between projects (even if scoped to single projects) without being a site admin?

Any insights, tips, or best practices would be greatly appreciated!

Thanks in advance!

[Walter Buggenhout]

Hi @Sriram Mishra,

The right thing to do here is involve your Jira Administrator at your organisation to update the scope of your automation rules for you.

Since those rules are probably doing the same thing, broadening the scope ensures that you only have one rule performing the actions. If you start copying them and something needs to change in the future, you would have to update all the separate copies to apply the change.

There is also a limitation on the number of rules you can execute on a monthly basis in your site. So it is not a bad thing to have some governance in place around this centrally, as it may impact your bill (since you are on enterprise, that is not really an issue, but for many customers it is).

I understand that in larger enterprises it can slow you down if you need assistance from central IT to move you forward. But on the other hand, if you like doing this automation work, you might be able to make a case to help them out and get an upgrade of your permissions internally ...

On a final note, there is also a possibility to export your automation rules to a json file and then import them again (e.g. for migrating them to another site), but - unfortunately - that has to be done through the global administration as well. It also requires the involvement of an admin in your organisation.

Hope this helps!

[Sriram Mishra]

Hi @Walter Buggenhout

Thanks so much for your thoughtful response — I really appreciate you taking the time to share your perspective!

Interestingly, much of what you’ve mentioned aligns closely with the points I raised in my original question — especially around the limitations of scope changes and the need for site admin involvement. That’s exactly the challenge I’m facing.

In my case, getting support from our Super Admin team is extremely difficult. Even for minor help, I’m required to raise a support ticket, and the response time heavily depends on the current queue load, which often leads to delays. So, while I completely agree that using a single rule with a broader scope is the cleanest and most maintainable approach, the reality is that I’m entirely dependent on the Super Admin for any such change — and that’s where things get stuck.

I had also looked earlier into the export/import option using JSON, but as you rightly pointed out, that too requires global admin access — so unfortunately, it doesn’t help much in my situation either.

That’s why I was hoping there might be some workaround or permission model that allows Project Admins to at least copy or reuse rules across projects, even if scoped to single projects. Just being able to move a rule from one project to another — without recreating it from scratch — would be a huge time-saver and reduce the risk of inconsistencies.

Thanks again for your input! If you or anyone else has come across creative solutions or tooling that could help in such scenarios, I’d love to hear more.