Taking the Work out of Workflows - Recap

Kimberly Deal _Columbus ACE_
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
March 15, 2019

Happy Friday!

Here are some tips and notes from our Atlassian University: Taking the Work out of Workflows workshop from our Feb 27th meeting.

Simple Workflow:

A simple Jira workflow example

Anatomy of a workflow
Status - Where an issue is in the process.  Status should be unique and describe whats happening.  the example above shows the process flow for a book at the library.  It can only be in one status, At the Library, With Customer and Retired. Status should be kept to a minimum and wording kept generic to be able to share status across platform with other Jira projects.  Being too specific can be confusing, as to what status an issue should really be in, and can cause issues to have to be transitioned though unnecessary status to get to the correct one.

Transitions - How an issue moves to the next Status.  A book is checked out, checked in, or retired.  Simplicity is key here too, as long Transition names can make for a cluttered issue view and long names on transition buttons.  Many things can happen on a Transition, such as setting Conditionals, Validators, Triggers, and Post Functions.  You can also create screens to gather more information, as an issue move further though the workflow, such as Why a book needs to be Retired, or in a development space, what steps were taken to QA/test the code.

Resolutions-Resolutions define when an issue is Completed or reached the end of the process.  Just transitioning to a status that you consider completed isn't enough.  Jira keys on the Resolution in a lot of default JQL queries, and Resolution must be set properly filter for that.  It is also important to clear the resolution if the issue is reopened. It is common to set a screen on transitions that move an issue to a completed status, prompting the user to enter a resolution and to use a Post Function to automatically clear the Resolution on a Re-Open transition.

 

Anatomy of a Transition:

Jira Transition.jpg

There are 4 Types of actions that can happen on a Transition.  Triggers, Conditions, Validators and Post Functions.  Triggers can work with other systems for integration, so we didn't get into those during the workshop and focuses on the other three. Remember some of options come standard in Jira Cloud, that you will need to add a App for in Jira Server.  Common Apps include Suite Utilities for Jira (JSU), Adaptivist Script Runner, Jira Workflow Toolbox and Jira Misc Workflow Extensions.

Conditions- define what has to exist before an issue can be transitioned.  If that condition is not met, there is no option to transition the issue.  Its hidden from view, until the condition is met.  
  Common Conditions: User must be in specific role, and specific group or has the correct permission & Status of subtasks 
Conditions can also be grouped and nested.
  Remember ALL is = to AND
                    Any is = to OR

Validators- Check information during a transition.  If this check fails the the issue does not progress to the next status, and if there are any Post Functions, on the Transition, they will not be executed. 
  Common Validators: Making field required later in the workflow, rather than on issue       creation.  Regular Expression checks or date comparison. 
Remember to add a screen to capture any fields you would require at this point in the workflow and that is it is best practice to use Project Roles, rather than groups or individuals in your Validators. 

Post Functions-automated actions that take place after an issue has transitioned.  These only happen if the Conditions and Validators that have been set, pass as True. 
  Common Post Functions - fire an event for the listener.  That will send notifications based on events and notifications schemes, such as Issue was Opened/Closed.  Automatically set or clear a Resolution & update other system fields like Assignee, Description, Environment, Priority, Summary, Original Estimate and Remaining Estimate. This doesn't include Custom fields, you will need to add an App for additional functionality.  

Key Takeaways: 
In addition to the above, keep in mind:

  • Check to see what projects share a workflow, changes to a workflow will affect all projects using a shared workflow.
  • Keep your workflows, status and transition names as simple and generic as possible.  it will make them easier to maintain and keep your application tidy.
  • Use Post Functions to automatically set and clear resolutions.
  • Additional funtionality is great, but try to keep the Apps to a minumum, as workflows will cease to work if the App is uninstalled or the licenses expires. 
  • Test everything in a developer environment or a test project with no shared configuration. 
                                         


If you did attend, and were not able to fill out the survey at the end, I would very much appreciate it if you would.  The Atlassian University Team would like to offer more chances for us to host these type of events, but need our help to further that direction.
https://surveys.atlassian.com/jfe/form/SV_0IoEE58DP9qTG8B

Also the training discount codes will expire today, if you were thinking about picking up the OnDemand or Team Training. I'm quite excited to be picking up the Server Administration Cert Prep course for myself. Let us know what training opportunities you are excited to see! Here are those training codes again, if you didn't see them in the other post:


AUG Training Codes..PNG

 

0 comments

Comment

Log in or Sign up to comment
TAGS
AUG Leaders

Atlassian Community Events