Jira Cloud admins, what admin work do you wish you could safely delegate?

[GAAG]

I’m curious how other Jira Cloud admins deal with this:

There are some things project owners or team leads could probably handle themselves, but giving them broader Jira admin access just to do that can create a bigger problem.

Do you get recurring requests that you wish you could just hand off if there was a way to limit people to only the changes/options you were comfortable with?

I’m mostly wondering what kinds of requests keep coming back? How often they actually happen and whether they create enough delay or admin work to be annoying.

Also, are there things you would delegate today if Jira’s permissions were more granular? And if yes, what would you need before being comfortable with it? Audit history, only approved choices, rollback, approval... something else?

And if this really isn’t much of a problem in your environment, that’s useful to know too.

How are you handling it today?

Thanks!

[Colin_McDermott]

Groups, workflows and custom fields. 

it's very simple, we use groups in filters and other areas. 

We just want people to be able to add users to groups and remove. Nope it has to be an 'admin' function. We were hoping to use teams for this, but teams isn't supported in JQL filters :(

Workflows too. Often even when a workflow is only used by 1 project that projects administrator cannot edit even with extended permissions. Plus the same person can be admin of the same 3 projects that a shared workflow is used with and <access denied>. 

Lastly custom fields and options within custom fields. We have teams that want to adjust a list of options in custom fields. Super common request. They can't do it, so they have to engage the Jira admin to do it, which brings on the usual fight to get the field added to the screen etc. A huge help would be editing which options are available in custom fields, even if DELETE is blocked. 

i.e. field - select list: server_type

tiny

medium

large

xl

adding type 'small' shouldn't be an admin job. adding project scoped custom fields shouldn't be an admin job IMHO but adjusting those options would be super helpful. 

[Akina Dudde]

We have developed a PHP page that users can access via the intranet to manage specific groups.
The page then communicates with the Atlassian API and makes the changes to the group.
A service account is used for this purpose, which has the permissions to modify the groups.
This also allows us to give product owners the ability to manage licenses for the product without granting them elevated permissions.

[s_gridnevskii]

Does not look really safe for me if they can type or inject group name. Just imagine if everyone adds himself to jira-administrators :)

Even if frontend is 100% reliable the backend can be vulnerable. If intruder knows that jira admin tocken is somewhere on the web site he will attempt to attack infrastructure.

[Akina Dudde]

There is a drop-down menu listing the groups you are authorized to edit. In the backend, the permissions of the person attempting to perform the action are checked again to verify that they have the necessary permissions to add or remove members from the group.

The backend also verifies that an email address is provided.

I can't say exactly how secure it is, since I'm just a user of the tool myself

[s_gridnevskii]

I allow employees to admin spaces/projects. If employee is VIP (e.g. head of department) he may have jira admin rights, but only if Security department approves and for a specific period of time. I have backup in IT department who can replace me if I am on vacation, but he has clear instructions not to get involved in changes he does not understand completely.

[Hugo Mora]

Hi everyone.

Answering your questions in order, from a consultant's sample rather than a single instance.

What keeps coming back: select-list options (weekly, in every instance), group membership (weekly), adding an existing field to a screen (monthly), a new status or a tweaked transition (monthly), permission changes for a new contractor (constant). @Colin_McDermott's list matches mine almost exactly.

Why the granular-permissions framing only half works: the reason a project admin can't edit that workflow isn't really permissions, it's sharing. The scheme is used by twelve projects, so there's no scope at which the change is safely local. More granular permissions on shared configuration just gives you a smaller way to break someone else's project.

So the prerequisite for delegation isn't a permission model — it's unshared configuration. Where a project has its own workflow scheme and its own field context, delegating is already fairly safe today. Where it doesn't, no permission granularity fixes it. Field contexts are the underrated one here: a project-scoped context means one team's option list changes affect nobody else, and that turns Colin's "adding 'small' shouldn't be an admin job" into something you can actually hand over.

What I'd want before delegating: honestly, reversibility over approval. Approval queues mostly relocate the bottleneck and decay into rubber-stamping within a quarter. A bounded set of choices plus a log plus a clean undo covers more real risk than a signature does.

On @Akina Dudde  's patter — that's the right answer available today and I've built the same thing more than once. One warning worth stating: the Jira audit log will attribute every one of those changes to the service account, not to the person who clicked the button. You've solved the permission problem and created an attribution problem. Log the requesting user on your side and keep it as long as you keep the audit log, or the first time someone asks "who added this group member in March" you'll have nothing.

Also worth watching that service account like any other high-privilege credential — scoped token, expiry, and rotation. It's a small tool with global admin rights behind it.

Cheers, 

--Hugo

[s_gridnevskii]

>  The scheme is used by twelve projects, so there's no scope at which the change is safely local.

It is only one side of a coin. Imagine a project with 20000 issues (sorry for my old slang) and employee who has little experience in jira administration deletes some statuses and replaces them with new statuses and transitions. If he applies changes without thinking

1. Users may receive 20000 emails concerning status change
2. Automation rules may stop working.
3. Agents that use this project may start making incorrect assumptions spending lots of tokens.
4.  ...

The most obvious action like adding a transition from On Hold to Done may lead to problems since employees may have no idea that resolution field is empty. And they will run to you and ask why their graphs started to show Done issues.

I strictly object letting users alter workflows. If they want to play - make a copy of your Jira on a test server and let them play. 

[Hugo Mora]

@s_gridnevskii  the time-boxed VIP admin is a good pattern, and I'd ask one question about it: what actually revokes it when the clock runs out?

Jira Cloud won't do it for you — there's no expiry on group membership or on the admin role. So "for a specific period" is only as real as whatever removes the person, and in most places that's a human remembering. Every instance I audit has a jira-administrators group with two or three people in it who were granted access "temporarily" during a project that ended in 2023, and nobody can say who approved it. If your revocation is a calendar reminder, it works until the week you're busy.

Cheap fix if you haven't got one: a scheduled job that reads the admin group members and alerts when anyone appears who isn't on a short static allowlist. It catches expired grants and unapproved additions with the same check.

The other thing worth separating: time-boxing limits credential exposure, not change risk. The damage a well-meaning head of department does isn't spread over the 30 days — it's one change in the first afternoon, and it outlives the access by years. Duration is the wrong dial for that; visibility of what changed is the right one.

And the honest bit of your setup that I'd point at: your backup has instructions not to touch what he doesn't understand, while a VIP with 30 days has no such constraint and more nerve. Worth asking what those VIPs actually do with the access — in my experience it's usually one specific recurring task, which means it was never really an admin-rights problem.

Have a nice day,

--Hugo

[Becker_ Rene]

For me it's the tab bar on top of spaces (where it says List, Boards, Details, Summary, ...) and Boards themselves.

Also Components would be nice. It's one of the major topics (me sitting on the permissions and users needing them)

---

[GAAG]

@Hugo Mora , this is really useful, especially since you're seeing it across multiple instances.

You mentioned you've built the service account approach more than once. What usually pushed it over the line from "annoying admin requests" to actually being worth building something for? Volume of requests, turnaround time, security/governance, something else?

And out of the things you listed, which one tends to cause the most actual pain rather than just being annoying?

Good point on the attribution issue too. I hadn't thought about the Jira audit log only showing the service account.

[SPHIOR]

You listed four things you'd want before delegating — audit history, only approved choices, rollback, approval. Context for where I'm coming from: I spend my time on Jira configuration change records, which is why audit history is the one item on that list I'd push back on.

The audit log tells you that something was changed. It is much weaker on what the change contained. For the delegation case that's the wrong shape: you find out an edit happened, not what to undo. Before you rely on it as the safety net, do the cheap test — have someone add one option to a select list, then go and read what the audit log actually shows you about it. Decide afterwards whether that entry would let you reverse the change six weeks later without asking the person.

On Colin's custom-field example, I think the asymmetry there is the whole reason it's still an admin function. Adding "small" to a list is close to zero risk. Deleting an option is destructive and quiet — it takes the value off every issue that had it, with no confirmation of scale. A delegation model that treats "edit options" as one permission has to be as restrictive as its worst operation. Splitting add from delete is the change that would make this safe, and it's a different request from "give project admins more power".

Akina — the PHP page plus a service account is a real answer to the permission problem, and s_gridnevskii is right about the injection surface. There's a second cost worth planning for: every group change made that way is attributed to the service account, not to the person who clicked. You gain the delegation and lose the actor, which is precisely the field anyone reviewing access afterwards will ask for. If you keep that design, log the human on your side at the moment of the request, because Jira's own record won't have them.

Genuine question back, since you asked what recurs: for those of you who have delegated something successfully — was it approval that made you comfortable, or was it that the change was reversible? I suspect people say "approval" and are actually buying reversibility, but I've never seen anyone test which one they'd give up.

[GAAG]

Thanks, this is really useful. That distinction between adding and deleting options makes a lot of sense. I was thinking of “edit options” too broadly.

Your approval vs reversibility point is interesting too. In the environments you’ve seen, would reliable before/after history and a clean rollback usually be enough for routine low-risk changes, or do teams still want an approval step even when the change is easy to reverse?

[SPHIOR]

Direct answer first: yes, with one condition — that somebody actually reads the history. And I should be straight that I don't have Hugo's or Maria's sample. I work on the change-record side rather than running a large estate, so treat this as a hypothesis.

Maria's point about approval steps decaying into rubber stamps is the part of this thread I keep coming back to, and it is worth asking why they decay. An approver who signs off two hundred changes and never sees one of them cause harm stops reading them. That is not laziness, it is the absence of feedback. So approval fails hardest exactly where changes are quiet — where nothing visibly breaks afterwards.

Rollback fails in the same place. A reversible change nobody notices for six weeks is not reversible in any useful sense; you have made the cleanup possible, not likely.

Which means rubber-stamped approval and unread history are the same failure wearing different clothes. Both assume an attention that nothing in the system is actually producing. That is why I would put the weight on detection rather than on either control — not "can this be undone" but "will anyone find out it happened".

It also predicts which delegations go wrong. Change a workflow and someone's board breaks that afternoon; s_gridnevskii's cascade warning is that feedback arriving loudly, and you will hear about it. Add a grant to a permission scheme and nothing visibly happens — trivial to revert, and nobody will, because nobody knows.

One qualifier on treating approval as an optional last resort: in SOX, J-SOX or SOC 2 scope, approval for privileged changes is a control requirement rather than a risk judgement, and reversibility does not discharge it. Worth keeping "would this be safe" and "would this pass an audit" as separate questions, because they do not always give the same answer.

To make it testable — for anyone who has before/after history in place today: when a low-risk change is made without approval, how do you actually find out? Does the history surface it to you, or do you only notice because you went looking after something else went wrong?

[GAAG]

That's a really useful distinction. I think I've been lumping detection and reversibility together more than I realized.

Maybe the cleaner way to think about it is prevent, detect, recover. Approval is one way to prevent a bad change, history and detection help you find it, and rollback gives you recovery. A reversible change that nobody notices for six weeks is obviously a very different thing from one that gets caught quickly.

The permission example makes that especially clear because the dangerous outcome can be completely quiet. And your compliance point is important too. "Would this be operationally safe?" and "Would this satisfy the control environment?" really are separate questions.

This is exactly the kind of nuance I was hoping this thread would surface. Thanks.

[Maria Reisinger _MetaFrazo_]

Great thread. @SPHIOR's point deserves more attention than it's getting: the audit log tells you that something changed, not what it contained. That's the gap that decides whether delegation is safe.

We ran into exactly this building event-based change tracking for Jira. The native audit log is a list of "someone touched this" entries. What you actually need for delegation is the event level: which option was added to which field, what the value was before, when it changed, and whether it changed again two weeks later. Once you have that, the reversibility question answers itself: you can only undo what you can see.

On @GAAG's last question (approval vs. rollback): from what we see in real instances, approval steps decay fast. After a few weeks they're rubber stamps, exactly as @Hugo Mora  says. But a complete change history never decays. It's also the only thing that survives an audit: "who changed this in March" is answerable from events, not from an approval checkbox someone clicked.

So my order would be:
1) unshared config where possible (Hugo's point),
2) full before/after event history,
3) split destructive from additive operations (SPHIOR's add/delete asymmetry).
Approval last, if at all.

[GAAG]

Thanks Maria. The point about approvals eventually becoming a rubber stamp makes a lot of sense, and I like the distinction between additive and destructive changes.

In the environments you’ve worked with, are there any Jira configuration changes you’d consider safe enough to delegate if the before and after state is captured properly and there’s a clean way to undo it, versus others you’d simply never delegate because the blast radius is too high?

Thanks again.

[s_gridnevskii]

I guess sprints, components and versions are safe to delegate, as well as screens. Field configuration is less safe since employees may not understand the concept fully. Workflows, permission schemes, notifications and rules are no no. Only admin together with user.