2 issue types with their own workflow versus 1 issue type/1 workflow

[Boyd K]

New to Jira (Data Center, since self-hosted/managed) and trying to setup the projects, issue types, workflows, etc.

So one of our team projects will have two types of changes to work.  Either software changes that involve a CM build or environment/network changes that involve a few more gates of reviews and approvals.  Thus, the workflow of the environment/network changes has a few extra states than the workflow of the software changes.  So, I thought of having one issue type for software and the another issue type for environment with each having their own workflow, yet in the same team's project.  Also to note, the issue type for environment will have a few more issue fields that don't pertain to software.

Now, I have been questioned why have two different issue types?  Couldn't there be a flag (field) to distinguish between software change and environment change?  Then, based on that flag, allow only the state transitions and states applicable for that change.  Thus, software changes would never see state transitions that move them to states only intended and applicable to environment changes.  Thus, there would be one issue type and one workflow.

Thoughts?  I am anticipate the one issue type / one workflow may make the workflow maintenance more complicated but then again I am new to all this and perhaps it's all easy.

[Eugenio Onofre]

Hello @Boyd K

In my opinion, the option with a single workflow makes more sense but, as you antecipated, may add complexity to the workflow, as you would need to add validators and post functions to achieve the desired behavior.

[Boyd K]

Is there a disadvantage of having two different workflows (or issue types)?  The one workflow for the software changes will also be used in other teams' projects.  The other teams do not work any environment changes.  Thus, if we just go with a single workflow, it would be the one for all changes for all projects.

Also, I anticipate that the workflow for environment changes may change down the road and, of course, I would not want any workflow change in any way to affect the workflow for software changes.

Any further thoughts?