Custom workflow for change management

[John Rummell]

I'm evaluating whether or not we can reproduce our current change management process in JIRA workflow. This is what it looks like.

1. Developer submits form to dev manager with change request (update/install app in production environment)
2. Manager sends the form to various people for approval (DBA, IT Manager, Sys Admin, etc)
3. Once manager recieves all required approvals he approves the request
4. Developer works with DBA, Sys Admin, etc to perform the change

We'd like to use JIRA workflow to automate this, as we're currently passing around lots of emails. The part I'm not sure about is how to assign multiple approvers to an issue. I saw that there is a Multi User Picker custom field type, but I'm not sure how to turn that into assignee(s).

I understand that each assignee could approve and assign to the next approver (or back to the manager) but we'd like workflow to automatically assign to the next approver or if all have approved, assign back to the manager. Is this possible?

[JamieA · Accepted solution]

For multiple approvals my general advice would be to create a new sub-task Approval issue type with a simple workflow (open->approved, open->rejected etc). Then create as many subtasks of type Approval as you need.

There are plenty of plugins that can help here with either creating a bunch of subtasks automatically after a transition on the parent, and you can use the "subtasks blocking" condition to prevent the parent moving until all subtasks are approved.

Also there are postfunctions that can automatically transition the parent once all subtasks are approved.

The advantage of subtasks is that the approvals can happen in any sequence, and you assign them to the approver so they get mails about it and it shows in the "assigned to me" filters, and so on.

> Is this possible?

Certainly possible but you might need to do a bit of programming or at least scripting to get a seamless solution.

[John Rummell]

I don't mind a bit of programming :)

[Dieter]

In practice we also work like Jamie recommemds. in addition i'd like mention a feature that is unfortunately not used in JIRA though it technically could be. it's the abilloty of the osworkflow framework to split the workflow to several independant steps. after each step has executed the approval step the wokflow joins again to a single thread. How this can be leveraged is described at http://confluence.atlassian.com/display/JIRACOM/Unordered+workflow+transitions+(eg.+issue+approval) If you like experiments, give it a try but: it is not supported!