Allow a Project Lead to edit workflow without global Admin access

[Peter Drier]

We have project leads that need to edit their workflows. We can't give all project leads global Admin access. How can we solve this situation?

[Nic Brough -Adaptavist- · Accepted solution]

You can't. To edit workflows, you need global admin.

If you have Greenhopper though, you can use "simplified workflows"

[Peter Drier]

eerg.. I was afraid of that.. And it's goign to cause us some sarbanes oxley issues if they don't fix it. basically, we can't have business users with admin if our code is in the same ondemand.

Given I was able to find requests in the Jira Jira for this from ~2006, it's a shame they haven't sorted it by now.

All we'd need is a permission allowing workflow editing for non system/default workflows. Either on a one-off situation, or for workflows tagged/tied to a project.

Ideally, a project admin could clone/copy the default system wide workflow, and edit it.. No harm outside that project.. (possible crazy workflows sure, but the editor is pretty straightforward these days)

[Nic Brough -Adaptavist-]

I'm not sure it's going to be fixed any time soon. There's a good reason to prevent project admins having access to the full set of workflow options (I'd say one quarter of my career with Jira admin has been made up of cleaning up the mess made by "oh just give everyone admin rights").

In fact, thisu control is better for SOX compliance - it means you've got a tiny handful of responsible people that you need to trust anyway - your admins. You can point at it and say "it's all locked down, if any data goes missing, it was an admin, there's no way a PM could hide stuff"

There is some movement though - the Greenhopper simplified workflow allows a project admin to set up a skeletal workflow without getting any other system rights.

[Peter Drier]

Don't know if I'd call the greenhopper simplified workflow a workflow at all (it's everything to everything star pattern at best).. but yes, that might quell the "need" by folks higher than I in the food chain who "have to" to edit their own workflows.

And part of the original desire for workflow editing would help with SOX as they could edit the workflow without having delete perms on the issues themselves.. We already had to remove the delete permission from admin (they don't know how to find it to turn it back on thankfully).

Anyways, thanks, I'll try the simplified route tomorrow.

[Nic Brough -Adaptavist-]

Same here - it's definitely aimed at projects that don't really have much in the way of a fixed process to go through. Good for agile development processes, and good for simple to-do type stuff, but a lot of people use workflows to mirror real life processes. For example, getting systems from development to production, via sets of plans and authorisations, which means things MUST be done in a limited order.

[Peter Drier]

yea.. for my project I tried to add a "Test" step between open and resolved.. but I want the developer to "resolve" it from open into test.. and then have the originator test pass/failed it into resolved (or reopened).. but in that first resolve step, the resolution gets set and the jira is "done" strikethrough throwing off other jira widgets.. turned it off for now, but that was the goal..

[Tod Shannon]

This is really a limiting function.  We are using an enterprise JIRA setup which has many JIRA projects from many different organizations.  The administrators are very removed from the users - they (naturally) have a very different role than the Project Admins.  The Project Admins (or some other permission) should be able to manage the workflows for their own Projects.  The simplified workflows are pretty limiting.  I'm kind of shocked this functionality is not there.  It sounds like to define a workflow I need to go through a third-party who doesn't understand my "business needs" and shouldn't really have to care about them, frankly.  They become a single chokepoint for organizations that are rapidly refining and/or changing workflows as project needs changes.

[Nic Brough -Adaptavist-]

I do understand that argument, it makes sense. However, in the real world, your project admins are not generally not skilled enough to be trusted with workflow construction (design, yes, but not translating that design into the signficantly complicated thing that is a real workflow), and that's really not what you want them doing - you want them running your projects, not spending days tweaking workflows and maintaining a system that is supposed to be there to support them and let them get on with their actual job. All but one of the jobs I've taken in the last 12 years has started with "Could you clean up the mess made by inexperienced admins screwing up the config?" Often fields, but it's mostly workflows that have been broken. The typical pattern of disastrous failure is "we made our project admins into system admins because they wanted to change the workflow". Workflows are complex. The vast majority of project admins do NOT understand the details. Having said all of that, try the "JIRA Agile" "simplified workflow" option. It really does simplify the workflow to the point where the project admins don't need Jira-workflow skills.

[Tod Shannon]

I totally understand what you are saying, but having JIRA Admin = Workflow Constructor and no other option is too limiting, IMO, because it assumes too narrow and specific an association of responsibility. I'd rather have a rope long enough to hang myself with rather than one a little too short to climb out of the hole someone pushed me into!

[Nic Brough -Adaptavist-]

That still leads you into "our workflow is utterly broken and we need help fixing it". Seriously. People editing workflows *need* to understand how they work, and that's simply not the case for most of us.

[ironSource IT Department]

That's a shame. It's not Atlassian's job to tell companies who should edit workflows. The companies should have the ability to decide if they want X or Y to be able to edit workflows *without* giving them *admin* rights.

[Nic Brough -Adaptavist-]

Have you tried editing a workflow? More importantly, have you ever supported a JIRA where a non-JIRA admin has been messing with a workflow. It would be great to be able to delegate workflow maintenance, as I said before. But because of their complexity in their current implementation, you simply can't afford to do it (irrespective of the other admin rights). You *will* end up with a lot of badly hung corpses.

[Michael Culley]

I fully agree. This functionality is badly needed. We have different business units using Jira and they really need access to change their workflows without us giving them access to delete users etc.

[Tareef Dedhar]

So, can we have someone explain why exactly JIRA feels that users are so incompetent they must restrict usability to prevent them from their own inability? To the point where not even having the ability to opt-in to a setting to give them the power, no, that's still too much for our poor users, but just restricting the ability entirely. 

Many enterprises have a single team who administers JIRA for the organisation, to simplify things from a cost and maintenance standpoint. This is normal, expected, and should be accounted for. Obviously, the dozens, hundreds, or even thousands of users/teams will have different needs for workflows, notification setups, etc. Not everyone is the same, and in larger organisations, the type of work can be completely different. Yet, from what I can gather from reading the responses on this issue, JIRA is of the opinion that since some users give the wrong people admin access and they mess settings up, we shouldn't have the power to give the right people access to change settings for only their own domains, because what if they're bad at it?? 

In my opinion, it is not JIRA's job to tell me my project manager is incompetent. That's their boss' job, and they'll deal with it when that occurs. JIRA should be providing us with good software that enables us to manage our team and projects better. However, it seems that they'd rather try and demean the capabilities of their users, and lock out critical features to that end. PLEASE reconsider this approach, and even if it's an opt-in setting that's disabled by default, allow admins to make the conscious choice to let certain project admins control their project when necessary, because as you know from the amount of posts about this both here and on forums, stack overflow, etc. it is something many users clearly need. 

[Nic Brough -Adaptavist-]

Experience and evidence. 

More than half of my career with Jira has been "fixing the mess made by people".  Not so much their own mess, but the mess they make when they break other people's stuff.   To the point where we removed project admin rights globally as a result of "not wanting to have to spend even more time satisfying auditors and sacking people".  I've seen weeks or months of work that could have been lost (sacrificed for "forget today's work folks, someone means we need to go back to last night's backup").  We have to assume people who can get it wrong, will, and badly.

Atlassian have some work (which is still continuing) on allowing people to have more local control of their own stuff, but it takes a lot of re-engineering.

[Michael Culley]

This sounds like an excuse for the mess that is Jira admin. The choice should be ours

[Sanne Pasveer]

Agreed, the choice should be ours. As a user I want to be able to allow ambassadors, that are well capable of designing workflows, to do just that. A permission scheme for that purpose should be connectable to the role of e.g. Jira specialist. 

[Nic Brough -Adaptavist-]

And, when you have that choice, if you pick the wrong way, you end up in a complete mess.  There are entire companies built on fixing the mess made by people who think they know what they're doing.

[Sanne Pasveer]

Dear Nic, as an educated person you can’t seriously agree with your own answer. When an employee understands the workflow functionality, and you give him/her the permission to manage hisbown workflowscheme and workflows, there is no difference from having one administrator with the same knowledge perform the same actions.

In the current situation there is only one option and that is to provide Jira Administrator rights to the one that want’s to manage his own scheme and workflows. There is more risk involved in that than in giving permissions for managing workflows alone.

In my opinion Atlassian should provide a better alternative.

[Nic Brough -Adaptavist-]

I think you've missed the point here.  If an employee understands it, there is no problem - they won't make a mess.  The point is that you should not let people who do not know what they are doing have the access to inflict their ignorance on others.

The "better alternative" is "don't let the incompetant break anything outside their own stuff".  Which is what we have at a higher level and has been cascading down over the last couple of years.

[Panagiotis Koskeridis]

Is this still not fixed?

[Nic Brough -Adaptavist-]

It is fixed.  In real life, project leads editing workflows is an unmitigated disaster, so it's not going to happen like this.

In JIRA Software, you have the option of "simplified workflow", which gives them the ability to set their own status and flow, but none of the clever stuff that so often goes hideously wrong.

On the plan for later, I understand that the aim would be for project admins to choose workflows from a list that admins define.

[Michael Culley]

I'm the customer and I say we need it. If we get in a disaster that is our problem. The world is not black and white and we don't have admins who are absolutely brilliant and the rest of the world who are idiots. We have a range of people with various skills.

[Nic Brough -Adaptavist-]

Well, in 7.3 it is now possible, to a limited extent.

For what it's worth, we've already picked up several pieces of work for "cleaning up the mess made by project admins when let loose on the workflow", and the ability to turn it off was added to 7.4 as a matter of urgency, as it created a massive spike in support calls to Atlassian from what I heard.

But if you're happy with the risks, upgrade and take a look at your projects.  If a project is using a workflow that is not shared with any other projects, then you will find project administrators can edit it.  They can't get at all of it, but they can design their own now.

[Sanne Pasveer]

It is now 2019 and the situation still seems the same. In the above discussion there is a limitation in your approach to reality.

You discussed the administrator and the project-lead. The role missing is the workflow specialist. Not every JIRA administrator understands workflow well enough. Some project leads understand it better than others.

I would very much support the adding of a role the allows some people to control workflows. I could then even organise a course to educate them in just that. Right now this is not possible. Its all or nothing. So I would really allow for the in between role. The workflow-specialist.

[Anette Lodahl Andersen]

Hi guys,

Can you tell me how I ensure my Project leads, project managers and/or scrum masters can be allowed to change their project workflows themselves? It's currently creating a massive overhead having our admins (IT support unit) being responsible for this. They have NO knowledge of how projects are run and the processes and flows needed. Indeed every project is different and there is most often varieties is needed for each workflow to optimise it for that team, client and project, in the end allowing us to fully utilise the Jira tool to create maximum value for our clients.  

[Nic Brough -Adaptavist-]

Please see the answers given 8 years ago about enabling "simplified workflow" - it's not changed much since then.

[Anette Lodahl Andersen]

Sure, but how? 

Would I need to change all our workflows and/or schemes to ensure they are 'simplified'?

[kylastearns]

I may or may not be on the same line of thinking as represented here, but I just had this issue come up yesterday and, being new to the organization and JIRA, was curious about it. The Project Lead was unable to delete a test project they created, or edit/change issues. I originally thought maybe there was a way to make the Project Lead also the Project Admin, but I can see where that isn't necessarily the best option all the time. However, I finally found where I can assign the person as the admin on individual projects. So it seems, for now at least, I will just do this when a specific complain comes to me. We are also a large organization with many projects in many areas of the business.

[Nitin Malhotra]

Thanks Nic

Can they rename/delete as well?

Does it work with just the JIRA default simplified workflow?

also - what is the impact of this on other projects using that same workflow?

[Nitin Malhotra]

Ok, so they cannot change (add/delete/rename) statuses, transitions etc...

Thanks... appreciate it.

[Nic Brough -Adaptavist-]

They can change status (in a simplified workflow). If they add a column, they can create a new status for it.

Transitions are simplified to "you can always move from one status to any other". Permissions and the rest are also simplified and fixed.

[Nitin Malhotra]

That's it?

Thanks Nic! Appreciate it...

[Nitin Malhotra]

Hi Guys,

i have a similar situation.

are you familiar with any development on this front?

If not, can you tell me how do I give someone access to modify the simplified workflow without rest of the admin rights?

Thanks

Nitin.

[Nic Brough -Adaptavist-]

You can't do it. Only administrators can edit workflows.

Simplified workflows are different - they follow the columns set up in the board for the project. That means anyone who can configure the board can configure the workflow. But only in a very simple way.

[Nitin Malhotra]

Ok thanks but how can they edit this workflow?

[Nic Brough -Adaptavist-]

The columns match the boards. They edit the columns on the boards, and the workflow follows the columns they define.