Are per project workflows ok now?

For a few versions now, the new project wizard in JIRA seems to want to create a set of schemes (workflow etc) per project when creating new projects.

The new direction seems at odds with the performance data and guidance of the past.

I believe most of the white papers, and presentations at Atlassian Summit promote fewer workflows as being beneficial to performance and scale.

So while I'm aware you can still punt the wizard, and create a bare project to associate with existing schemes (or use templates), is this "old school"?

Is allowing each project to have it's own set of schemes OK now, especially in larger enterprise systems with hundreds of projects?


1 answer

Hey Mark!

In my experience, having per project workflows is absolutely okay, and is ultimately ideal for scaling and ease of administration.  From a performance perspective, yes, it'd be ideal to share as many schemes as you can across projects, but it's potentially dangerous as the number of projects grow, (for example, accidentally changing a workflow that's shared across many projects), and needs evolve.   I can't think of a single time where I've been able to attribute per project workflow schemes and/or other schemes as being a major culprit for performance degradation.  

(In my experience, one of the greatest offenders, (from a performance perspective), is having a huge number of custom fields.)

So, I say go for it.  It just may make things easier for you in the long run.  smile

I just +1'd that - huge numbers of workflows have never caused me a single performance problem.

Complex permission schemes, too many users, too many silly filters, extracts or integrations, yes.  But not too many workflows, or screen schemes etc.

I'd agree that the current limbo is a pain in the neck though.  As an admin, I like users to look after themselves, but also despise having 30 teams doing the same thing in 30 slightly different conflicting ways.  We now have the worst of both worlds - Atlassian actively encouraging individuality without doing anything to help admins manage or delegate it properly.  I'm hoping they get a grip on it soon, make a decision one way or the other.


It is semi-disfunctional.

On one hand, I like the notion of having per-project schemes, it cuts back on the number of "yeah, I can't do that without pissing off teams a b and c".

On the other hand, if I give teams per project schemes, it's going to be a cluster-f trying to make change A apply to these 90 projects, 25 of which the change will break....


Bother, can't +1 comments wink

Suggest an answer

Log in or Sign up to answer
Community showcase
Published Jan 08, 2019 in Jira

How to Jira for designers

I’m a designer on the Jira team. For a long time, I’ve fielded questions from other designers about how they should be using Jira Software with their design team. I’ve also heard feedback from other ...

1,165 views 5 10
Read article

Atlassian User Groups

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

Find a group

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

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you