Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

Allow project admins to edit shared workflows

I know project admins can only edit their workflow if this workflow is not shared with other projects.

But I have the following scenario:

One user is project admin in three projects and he'd like to use (and edit) the same workflow for all three projects.

So my suggestion is:

Allow project admins to edit shared workflows if they are admins in all projects which use this workflow.

1 comment

Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
Nov 27, 2018

I do not think that this is the vision that Atlassian is implementing. From one side they introduce ability to edit workflows but on the other as you mention it must have independent configuration (not shared). That is also introduced in a new "next-gen" project type in Jira Cloud.. (every project have own configuration)

I personally do not think that this is a good approach. Everyone knows that the best practice on Jira Server is to reuse configuration (if possible). That is also noticed in Atlassian University trainings. Adding features that push people to make configuration unique per project add more not needed objects in the database and overall over time means decreases performance.

As for your request I do not think it is good in many situations. Imagine that you have one admin that is only the admin of one single project and cannot be in 2 more. On the other side you have admin that can administer 3 projects. How would feel the admin of the single project if he see that someone else can edit his workflow but he cannot. He would like to have also that permission even that it requires making the configuration unique and loosing the flexibility of sharing.

Another thing is that your scenario is only for 3 projects. What would need to happen if you share the workflow with 10, 20.. or more projects? You would like to make admin only to give someone permission to edit workflow and do some small change that would break the company standards

For me this "Extended project administration" could be completely removed. It introduce more problems for experienced and certified admins than "good things".. In my Jira instance I have projects that have configuration shared with 400+ projects and imagine if everyone would like to edit their workflow. I would need to create 400+ unique configurations just to satisfy their needs. At the end I (as Jira admin) still need to help them because they cannot do this/that or cannot understand the workflow design principles.

So faster, cheaper and safer than giving them that ability is to ask Jira admins directly. This design was working for almost 15 years in Jira and overall not many people complained about that..

Like Steffen Becker likes this

Thank you very much for this detailled feedback!

Especially the 2nd and 3rd paragraph contain very good arguments.

But regarding the "ALL projects should use the same scheme", I handle it different than you:

In the past (and still in the present in many use cases) we use(d) "Ivanti Service Desk": Everybody I know hates this tool because of the bad UI & inflexibility. That's why we switched to Jira. I administrate about 200 projects. Most of them use our standard, shared company schemes. But some projects have different needs and there are very experienced Jira users who think they are limitated by our default schemes. If we would force them to use our default schemes, it would look like "another inflexible Ivanti" to them.

But this only happens for about 10% of the projects, so that's why we decided to create custom schemes on demand.


Log in or Sign up to comment