Assign a workflow based on select list custom field.

Question

Within our Change Management project, we have one issue type called Change.  This Change issue type has a custom field within the screen called Change Type that allows the users to select whether the change is an infrastructure, development, emergency, etc. change requests.   The change issue has a create/edit screen and a view screen.  Today, they all follow the same single workflow.

However, we want to breakout the Infrastructure change type (change type = custom field) to have its own workflow. Is there a way to use the same create/edit screen and use the users selection from the custom change type field to trigger which workflow to use?  Or will I need to create/copy the screen, workflow, etc for this?

Mike Rathwell · Answer

sigh I typed a long answer in here yesterday, didn't save it (distracted) and then not paying attention restarted the browser. So.. I'll try to remember what I wrote (and it was beautiful)

Anyway....

I'll start with there are a handful of things you can do out of the box with Jira in this respect. However to get "creative" you probably need to add a couple of things. Two items that are staples for me are Jira Misc Workflow Extensions (JMWE) and ScriptRunner for Jira. Between them they are kind of the Swiss Army Knife of extensions to do cool things with Jira. There are others I have in my system but these are used heavily. If you had to pick just ONE initially, I'd probably go with JMWE as it has a lot of the Groovy-ness and holds one's hand a bit more. ScriptRunner completes the picture with deeper capabilities and recent releases do more of the hand holding for you.

With those in, you get rather more items such as:

* More workflow conditions and validators that can have Groovy stubs to, for example, validate/test the existence or value in a given custom field
* The ability to conditionally have automatic transitions occur such as when there is a given value in a field
* Broader linked issue/subtask status tests for conditions, validations, and post-functions

As such, you have the ability for a given WF to follow different paths through itself based on what the contents of a given issue is. Moreover, if needed, based on contents of an issue, it can make linked issues or subtasks and validate their state.

This just touches the iceberg. What I'd suggest is to look at the docs for both of the add-ins I mentioned above. Those will give you a good look at the extensions and how they might apply.

Jeremy Upright · Answer

Hi @Mike Rathwell - Any chance you could elaborate a bit on how this would be done?  Any specific add-ons required?

Mike Rathwell · Answer

Hi @Kara Brake

While it could get ugly fast, one way you could to it is to have, essentially, all the workflows baked into a single one and which way it goes is dependent on the value in the Change Type field. So... for example, from the generic "To Do" start box, depending on the field type, transitions to the workflow branches that suit the change type are then visible while the ones not matching are not. At the end, have all the branches transition to a single "done" state.

While the WF could get ugly to look at (multiple WFs in one single screen) it has the advantage of easily being able to share common transitions like, for example, blocked, on hold, etc.

I have a few cases where I've got condionals for a small loop out of the norm and this could work for your case.