Are per project workflows ok now?

Question

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?

Nic Brough -Adaptavist- · Answer

Bother, can't +1 comments

Mark Montminy1 · Answer

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....

Nic Brough -Adaptavist- · Answer

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.