Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Deleted user
0 / 0 points
badges earned

Your Points Tracker
  • Global
  • Feed

Badge for your thoughts?

You're enrolled in our new beta rewards program. Join our group to get the inside scoop and share your feedback.

Join group
Give the gift of kudos
You have 0 kudos available to give
Who do you want to recognize?
Why do you want to recognize them?
Great job appreciating your peers!
Check back soon to give more kudos.

Past Kudos Given
No kudos given
You haven't given any kudos yet. Share the love above and you'll see it here.

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

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

Mirek Community Leader 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

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you