Creating a Custom Workflow

There are times as a JIRA Admin that you will get an odd request. Something that is well outside your strong-suit, but also something you can’t (or shouldn’t) say no to.

This happened to me at one point at my last job. the CFO of our small company came to me and my manager, saying that he had been told by our CEO that we needed to clean up our purchase order process, and that the CEO had told him to use JIRA to get it done.

Now, JIRA – strictly speaking – isn’t a finance tool. But, JIRA is a tool that can manage a process, and this was a process. So I told him what I’d need and what time frame we are looking at, and off we went to get it done.

I should note that I was working with a JIRA Software instance. There are some different ways to handle this in JIRA Service Desk, but I was limited to the version I was managing at the time.

Today’s post will be looking at the workflow that resulted from this, and how I came to the workflow.

Getting to know the pain points.

My Mom used to tell me a story about when she was in served in the U.S. Army. As a Sergeant, she developed a reputation as a “fix it” sort of leader. Put her in charge of a group, and she’d get them working together properly in no time.

One day, her Commander put her in charge of the company’s logistics group. Now my Mom specialized in Missile repair, not Logistics, and didn’t have a clue what they even really did. When she brought her concerns to her commander afterwards, he said this. “The team knows logistics, but you know how to lead. Trust them to know what they need to do and work with them to make sure it gets done.”

That story has stuck with me for some reason, and I find it oddly helpful in my role as a JIRA admin. You don’t need to know every little facet of how your teams do what they do, you just need to know what their pain points are and work to make sure they can get stuff done. If you become known as a problem fixer, your teams will let you know what problems need to be fixed.

Such as it was here. At University, finance was the one class that caused me the most problems. To me at least, it all seemed rather arbitrary, requiring lots of memorization. It’s the one class I had to work hard at to succeed in. But, as a JIRA Admin, I didn’t need to know every facet of Finance, just what were the problems they were trying to resolve.

So I sat down with the person the CFO loaned to me for this purpose. My first question was “What are the biggest problems in the current PO Process?”

I was told we had a paper-based process that required gathering actual signatures to move forward. However, as these papers were spread around multiple desks throughout the office, no one had any visibility into what had already started the process, what any one item was waiting on which signature, and double-ordering items because of this lack of visibility was a common occurrence.

Aha! There was the problem, and it’s one I knew I can fix with JIRA. With that, we move forward.

Drafting the workflow

With that discussed, I started asking about what the process should look like if it was to work as expected (ignoring the pain points mentioned earlier). I like to do this in front of a white-board – preferably with a few color options available.

As he goes through, I start building out a flow chart of what he is describing. It’s important to note that this won’t become the exact workflow, but it’s a way to work together to describe what the process currently is to come to a common understanding. So with these two bits of information, I go back to my desk and start working on the workflow.

What he described was a process where first the Manager would sign off on it, than the VP over that group. After VP approval was gotten, the Finance office would review it (usually the CFO himself). Here, depending on the price tag, the Finance office could approve it outright, or forward it on to the CEO for a final approval.

After all the needed approvals were gotten, it’d then be ordered, but no one was tracking when we received it, and lost items were also a thing that happened occasionally.

So with this, I came up with the following workflow:

So, what’s going on here? Well, one of the biggest pain points was that no one had any visibility on who a particular PO was waiting on. As such, I made the approval chain status “Pending X Approval”. But rather than use actual names, I made them positions so I can re-use them (this will come up later).

I also simplified this by making the re-assignments automatic for most of the workflow. This is done using the “Update Issue Field” Post function, with the field being “Assignee” and the Assignee being selected directly.

As an added level of security, I also made it where the current assignee was the only person who could transition a status, using the “Only Assignee” condition:

This may lead you to the next logical conclusion: What’s stopping a user from assigning something to themselves and moving it forward anyways? Well…this actually happened. I had over-looked this in my first version of this workflow, and someone (who I won’t name) reassigned something pending CEO approval to themselves and moved it forward. Lets just say it’s NOT a good morning when you get to work with the CEO waiting at your desk.

There is a solution here, however. If you highlight a status in the workflow editor, you will see a “Properties” option. These status properties allow you to tweak how an issue behaves at a granular level. Much respect to the J-tricks blog for showing me what options are available and how to do this.

Here I would put the first person with the ability to reassign to the user that was auto-assigned the issue. The second person was myself. Being a small company, there wasn’t a tools team, so I didn’t need to worry about making this a group. If you do however, you’d use “jira.permission.assign.group” as the Key and your group name as the Value. Be aware that this puts a magnifying glass on you, so people will know if you abuse the system yourself. Also, if you have more than one user or group keys, you will need to numerate them like in the example above. Otherwise JIRA will get confused. Odd, but true.

This works well for one group, but as you may know, JIRA doesn’t really know or care who a particular person’s manager is, or who their VP is. This honestly caused me the most problems.

However, the solution I came to was to have multiple workflows, one per group, and assign them to different custom issue types name for that Group. So we initially had “IT Purchase Orders”, “Facilities Purchase Orders”, “Engineering Purchase Orders” Issue Types. This allowed each workflow to be tailored to each specific group and track through their management chain accordingly. This is why using generic Statuses was so important earlier, as it allowed the same statuses to be used by all of these workflows.

After the approval chain, I added a couple of more statuses describing the wait for it to be ordered and delivered. This was to track an issue all the way to make sure it was actually delivered as expected – as this was a stated problem as well.

One last note I’ll make on this workflow. I added an open step at the beginning to give the requestor one last chance to review everything before sending it into review. This also gave me a status to send things back to if an approver didn’t want to reject a request, but felt it still needed more information from the requestor. However, this caused some requests – especially when I first put this process in place – to sit in this opening status because it was never actually sent for approval. You can – as an option – send things from issue creation directly to Pending manager approval, then just have an offshoot status for requesting more information that goes back into Pending Manger Review. I personally don’t like this option, as I like the “Are you sure?” approach to submitting requests. But, on the whole sending items directly for approval is technically sound and a valid approach.

Closing thoughts

Now, this wasn’t the whole project. I still had to go through three more meetings about what fields were needed, but that is another blog post altogether…probably something along the lines of “What to do when you and your users disagree.” But before I go, I wanted to thank my previous company and my former Manager. I actually had to get her approval to be able to share this story with you, as well as her encouragement that lead me to originally start this blog. So, until next time, this is Rodney, asking “Have you updated your JIRA Issues?”