Working as a consultant on JIRA and JIRA workflow, I have done some observations that I would like to share - hopefully brining some success into Your project and implementation.

 

KISS - Divide and Conquer

Break Workflow down into "pieces"

Keep Your workflows relative simple, and break them into sub-workflow handled by subtasks if possible. This has several advantages:

A. The overall administration and overview of the installation is simpler

B. Specialities, as different Workflow for same issuetype in 2 projects are easier to maintain, as over issue types can still share the same workflows

C. Parallel processing can be done on subtasks by several other Assignee's - whereas one large workflow is seriual on one Assignee at the time.

Have a loose view on restrictions and conditions

Also, take a loose perspective on restrictions and conditions, setting the workflow up with tight restiction breaks agility in the real world, for example under ilness and leave, issues can be stuck.

The human factor

Thing is to bring up a question:

 

Most of the time, "A" is the common (and powerfull) reason that drives the normal JIRA user.

One of the most common things I encounter, is the diversity between some one's reporting "needs" versus the number of steps in a workflow, lets take the good old "Incident Management" process (a small version), that could be:

Now, Support Managers what to log all times in all of the JIRA "phases" - hence 3 times:

• Diagnose done  (Status going from Open ->Under investigation)
• Investigation Done (Status going from Under investigation -> Under Resolution)
• Resolved (Status going from Under Resolution -> Resolved)

In real life, if the JIRA User handling the Incident is that same, he will typically make the 2 last transitions right after each other, or perhaps if this is late and he is tired, the next morning. 

I have seen this all the time in reallife systems:

 

The solution is (in this case) 2 parts:

A. Only to make steps that fullfills the drives/motivators mentioned above in the box.

B. Make a "post" function that collects/enter the correct times. In the case above, the Service is down before the Incident is created, and up before the user resolves the issue, there times can be entered manually. 

The use of Plugins and custom code

Workflow can be extended heavily with Plugins and custom code - but be aware this requires extra maintenance on the JIRA installation, and the risk of breaks are higher, getting raised for every extra plugin or code.

Is dont say, "dont use" - but "use with caution and keep everyting updated".

If You are using plugins and custom code, do keep an eye on the catalina.out and atlassian-jira.log for stuff as:

• Java Stacktraces
• Jelly Script errors
• Groovy errror
• Custom Field errors

Using a Log tool such as splunk or similar 

Documentation