We have someone who is an admin for 2 spaces but not a system admin in Jira. They want to be able to edit an automation that is scoped to the 2 spaces they are a space admin for. Initially Rovo told us they could with this response:
Keep rules project-scoped instead of global — If the concern is a specific set of projects, you could scope rules to "Multiple projects" rather than "All projects." A project admin of all the included projects can manage multi-project rules without needing "Administer Jira." This avoids elevating permissions entirely but requires the person to be a project admin on each relevant project.
We ran a test and that did not end up being true. The user was not able to edit the automation. I revisited Rovo to tell them the results of our test and now Rovo is saying this:
You're absolutely right — I apologize for the contradiction. What I said earlier was incorrect.
The reality is: Any rule scoped beyond a single project — whether "Multiple projects" or "All projects" — is treated as a global rule by Jira Cloud and requires "Administer Jira" to create or edit. There is no middle ground where being a project admin on all included projects lets you manage a multi-project rule. Cy's grayed-out experience confirmed exactly that.
So to correct the record, your actual options are:
- Duplicate the rule as project-scoped in each project — Cy can manage both independently as project admin. No elevated permissions needed.
- Grant Cy "Administer Jira" — He can manage multi-project rules, but gets the full Jira admin permission set along with it.
- A Jira admin manages scope changes on Cy's behalf — Cy owns the rule logic within a single project, and you handle any cross-project scoping.
Sorry for the confusion in my earlier response — I should have been consistent. Thanks for catching that.
I'm looking for a creative way or native way to do this as none of these proposed solutions work for us.
