Are per project workflows ok now?

Mark Montminy April 6, 2016

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

1 vote
105349
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
April 6, 2016

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

Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
April 6, 2016

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.

 

Mark Montminy April 6, 2016

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-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
April 6, 2016

Bother, can't +1 comments wink

Suggest an answer

Log in or Sign up to answer