This article covers 5 best practices, which will make your workflow creation process much easier. The workflows prepared by you will be easier read, maintained, and understood by the users.
As Jira administrators, we mostly create workflows based on the users’ requirements. Users generally require their status names to be as customized as possible, to perfectly match their business process which often leads to creating status names like „Change Accepted”.
We should avoid creating such statuses, especially if these will be used only in one specific workflow. In this case, it’s better to just use „Accepted” than „Change Accepted”, as it’s more probable that „Accepted” will be used in multiple different workflows. Moreover, if the issue type is „Change”, we don’t need to repeat it in the status name to make it understandable.
Keep in mind that statuses are the parameters most searched for by the users, so the more you create, the more confused and lost they will become. Also, adding a lot of statuses decreases your Jira instance’s performance.
While creating a workflow, we commonly add statuses and transitions between these. It’s always a good idea to remember to add a screen on every transition (between status changes). It doesn’t have to be a customized transition screen (though it can be). It’s enough if it’s a plain screen without any field added.
This way, on every transition, the user will have a possibility to add a comment under the transition. Moreover, this will force the user to confirm the status change, which will filter out 90% of the accidental status changes in your Jira instance.
Why is it important? Well, one of the most common requests to the administrators is reverting accidental status changes. It can be really, really annoying – especially in large instances. So it’s just better to avoid it.
While creating workflows, try to make them look as good as possible – make sure that the statuses are shown in order and that each transition is clearly visible for the users. It’s only a few minutes of your time and each of these minutes will pay off greatly. Why? Because when a workflow is easy to read, users have way fewer questions and requests to the Jira administrators. Also, the business process behind the workflow becomes more understandable.
When you’re configuring advanced workflows with many conditions, validators and post-functions, it’s generally a good idea to check if your workflow is working correctly after every change. Have you just configured adding an automatic field value after a status change, if a condition is met? Save changes and check them. Have you added a post-function that automatically creates an acceptance subtask after a status change? Save changes and test them.
A simple test takes no more than 2-3 minutes on average but saves a lot of time spent on searching which of the many changes has caused trouble in your workflow.
While creating a workflow, it’s worth remembering that not every state of the process needs to have a separate status. A rule of a thumb says that the fewer statuses the better. The process of deploying software to a production environment during a change process is a great example. We don’t need to create separate statuses for Deployment to Dev, Deployment to Test and Deployment to Prod. It’s enough to create a „Deployment” status and add a checkbox indicating to which environment the user has deployed the software.
Thanks to this, we can easily track all the changes in all environments by checking the checkbox field value, without a need to check the statuses at all.
By the way, we have a great workflow-oriented App available on Atlassian Marketplace – Workflow PowerBox.
Give it a try – we just updated it with a neat, new feature – Create Issues and Subtasks on Transition.