nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Is it better to have one workflow with multiple conditions or multiple alike workflows?

Ignacio Pizarro

I'm new on JIRA and project administration.

On my company we made multiple resources (like html pages, pdf documents, videos) that share the first half of the workflow, then have some different statuses and finally all go to QA. As can be seen, the workflow is 70% alike between resources.

So, is it better to have:

One workflow, with a custom field who defines the resource, and conditions in transitions based in this custom field, to lead the issue for a specific branch of the workflow.
A workflow for every resource.

I know that the problem can be done in both ways, but the question is which is the better way, in terms of UX, ease of maintenance, etc. to do this? There are certain things -like experience- that documentation does not collect

Thanks for your time!

Comments

Omar Herrera

Hi I prefer the second one because is native supported by issue type, you can educate and make a culture about the new process in your company.

Cheers.

Omar H.

Bastian Stehmann

Hi @Ignacio Pizarro,

I am with Omar, I would also use the second one. I think it is a lot easier to maintain that way.

Max Foerster - K15t

Hm, good question. You said it yourself in a way - "it depends". But if the overall workflow is thought through, I'd go with one workflow and maintain special transitions for specific resources making them available using conditions and using conditional executions on shared transitions' conditions/post functions for special tasks.

Best, Max

Ignacio Pulgar

It usually depends on the requirements, but provided you're on Cloud, I'd recommend using just one workflow, because of this existing bug:

https://jira.atlassian.com/browse/JRACLOUD-67800

That bug basically prevents workflow properties to work properly in projects that count with more than just one workflow set.

So, I'd try to use just one workflow as long as it remained a possible way of covering all your requirements.

If that bug didn't exist, then we should analyze all requirements to choose the best option. But while that issue exists, I'd prefer to be able to count with the possibility of using workflow properties, just in case I need them.

Scott Theus

I'd likely use more than one, but not ALL of the variations. I'd decide which workflows were the most used and include them, but for the lesser used flows I'd leave them out.

Gary Pasquale

I don't think you'll get a clear winner out of these two options. Comes down to personal preference.

I'd probably go with the second one. Splitting by issue type is slightly clearer from a users perspective and separate workflows are likely to give you more flexibility in the future as requirements evolve.

Having said that we're quite strict on names and numbers of issue types in JIRA. If your the same then the first option would work better. Categorising your issues using a custom field.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

cloud

jira-cloud