You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
Jira’s power comes from its workflows. That’s not a news flash and I thought I had a pretty good understanding of how Jira workflows worked – until I tried to create one. It sounds simple enough. Workflows have statuses (where an issue is in the lifecycle) and transitions (actions that move an issue from one status to another). If you’re new to working with Jira workflows, I would recommend reading this article, even before you dive into the Atlassian documentation.
At my workplace, we use a Kanban project to manage our content. It’s useful, but as the self-designated Content Queen, the person who uses the Project Board and someone with Administer Project permissions, I figured I could make it more useful (at least for me!). So I decided to put on my JA hat and customize the workflow.
I read that article. I looked at the Atlassian documentation. I scrutinized our team’s existing workflows. Then I figured I was ready to dive in and make the changes I wanted. I navigated the workflow used by the Content project. A friendly message said that it was, “Shared by 1 Project.” Since that one project was the Content project, my project, I figured it was okay to start to making changes. So I went to Jira settings > issues > workflows, found my workflow and started editing.
Bad idea! Later that day I learned that I had screwed up the workflow for our development projects. Oops. You see while the workflow itself was not shared by any other projects, all of the statuses within that workflow were. That’s because statuses are global. This means a few things:
While this was the biggest hiccup, I ran into a few other surprises. Examining one of my transitions, I noticed that it had 5 post functions. I hadn’t created these, so I figured they were just inherited from the workflow I was editing and weren’t needed. However, delete was disabled. I tried deleting and recreating the whole transition. Again, there were 5 post functions. It turns out, Jira creates these post functions by default, on every transition. Generally speaking, you don’t need to change these.
I did make one alteration. Based on Rachel Wright’s recommendation I changed the “Fire a generic event…”, to a “Fire an Issue Closed event” on my last transition. I also set a post function to set the resolution as “DONE” when the issue reaches its final status.
Another puzzle was how to deal with approvals. There are a lot of different options for creating approvals in Jira depending on the project type, add-ons, etc. You don’t want to have more statuses than necessary, and multiple approval statuses can create a bottleneck. The Jira Strategy Admin Workbook (page 86-88) describes how you can use transition buttons and field validators to enforce multiple levels of approval without creating extra statuses.
This fits with what appears to be the golden rule of workflows- Keep it simple!