Tag: Workflows

How to train your Workflows

Rodney N.Leave a comment

You know what? We’ve been a little system heavy the last few months. Lets try something different…

So, we all know JIRA workflows. They guide your issues through their life-cycle, apparently only know three colors, and otherwise just sit there, right? What if I told you that you can train your workflows to do tricks? It’s true!

Today we will go over some of the ways I have trained my workflows over the years, and when you’d want to use each trick. The ultimate goal here is to get you to see your workflow as an equal part of the issue life-cycle – that is to say not only as a faithful guide, but an active participant!

Some of these tricks will require a plugin to enable – but where so I will clearly mark them as such and give you a link to the plugin.

With that being said, let’s get into it.

Conditions, Validators, and Post Functions, Oh My!

So to get started, we’ll need to review the three parts of a transition: The Condition, Validator, and Post Function. Each of these are evaluated at a different part of the Transition execution, and therefore are able to do different things.

Conditions

These are evaluated any time JIRA needs to see if you are even able to see that the transitions exists. On the surface, seems straight forward enough. If a user doesn’t meet the conditions, they don’t see the transition, so what tricks could we do with that?

Trick: Secret Cleanup Transition

So, here’s the situation. As a part of your workflow, you require certain information be filled in to close issues normally. For example, you require a fix version be assigned to a new feature or bug. This is because your users had a bad habit of just closing critical bugs that really needed to be fixed.

Which is great, but as time goes along, the project lead comes to you, saying they have too many issues that being honest, they won’t ever get to. However, you realize that because of the requirements, you can’t just close those issues. You obviously don’t want to get rid of the requirements, but you want to enable the Project lead to do their cleanup. How do you do this?

We can do this simply with one condition! First we’ll add an “All” transition to the closed state we’ll call “Cleanup” Then we’ll put a condition on it that says only Project Administrators can see this cleanup transition. This way we don’t open up the workflow to the abuse we’ve previously tried to stop, but we give the Project lead the power to cleanup when they need to.

Validators

Validators are similar to conditions in the fact that they evaluate whether a transition could occur. However, the key different is WHEN they do their processing. Conditions are evaluated before a transition ever occurs. On the other hand, a validator is evaluated during the processing of the transition.

One thing Validators are great for is that when they fail, they provide an error message. When a condition fails, the relevant transition just doesn’t show up. From experience, this usually leads to a lot of panicked questions from new people saying “I can’t close an issue!” This problem is avoided entirely if you use a validator instead. “Oh, I can’t close it because I need a Fix Version – cool.”

Trick: Written Approval

Note: Requires JIRA Misc Workflow Extensions

So, you have an approval chain workflow, but you want to be sure whoever approved it really MEANT it. Lets say this involves a P.O. process, so you want to know whoever approves it really meant you to spend that money.

This is easy enough with JMWE’s “Comment Required” Validator. To make sure the phrase is added as, we’ll add a conditional to evaluate the comment field.

issue.getAsString("comment") != "I Approve"

This is a bit counter-intuitive, but the condition is what makes the validator active in JWME. Here, the validator only ever validates if the comment is anything other than “I Approve” – which includes an empty string! Having the comment be “I Approve” disables the validator and lets the transition occur!

Post Functions

Post functions have no evaluation purpose, but are executed “After” all conditions are evaluated and things are ready to move forward. This gives you a chance to update fields, fire off internal events or web-hooks, or a myriad of other tasks. Most of the time when I’m looking to automate some function that is based on a workflow, Post functions are where I’ll look to first.

Trick: Auto-assign on transition

So this is great for any situations where a specific person needs to do something on a specific status….such as an approval chain. This lets you set it up to reassign the issue on demand without having the user remember to take that action. Very Handy!

To accomplish this, we’ll use the “Update Issue Field” Post function, select “Assignee” from the drop-down, then select the last radio button to specify which user you’d like to transfer it to.

There are additioonal post functions from various Apps that will do the same thing, but you can do this with just vanilla JIRA Functionality.

Workflow Properties: The forbidden technique

Okay, so maybe I’m being a little dramatic…

Transition and Status properties are a powerful technique for customizing how your workflow behaves. However, they are somewhat hidden, dubiously supported, and tricky to get right. Basically, if you do choose to go this route, you will be pretty much on your own, with your only company being whatever articles you can google. By the way, Hi googlers! Welcome to the blog!

In general, I don’t really like to use Workflow properties, but there are some cases where they can’t be helped. One use case I’ve used them for is to limit who can reassign an issue in a given status…which being honest I learned from another blog.

To access the properties screen, select your transition or status of your choice, then click “Properties”

This will open up another screen where you can see a list of that item’s properties. By default there should be none.

Trick: Re-order the Transition buttons

So lets say you have a project lead that is a little…particular. They want the most relevant transition to be the first button, with anything else being second. But you can’t re-order the Transition buttons, right?

Well, I wouldn’t be writing this section if that was the case. We can use a property on each transition called opsbar-sequence. This is a setting that will allow us to specify which transition gets priority on the issue view screen. To do this, we’ll need to add the key “opsbar-sequence” to each transition, along with a unique value. It is recommend you increment the value by 10’s on each transitiono, so if you add more transitions later, you have a place to put them between existing transitions

Remember, in this arrangement, the lowest opsbar-sequence value will go first, with each increasing value following afterwards.

You are now a workflow trainer!

My goal here is to get you to think about different automations you can enable for your users. It may seem trivial to you, but if you can save them 10 seconds on each transaction, that can really add up over time. And you don’t have to stop with this list! Look over what post functions, validators, conditions, and yes even properties you have available, and keep an open mind when you get these unusual requests.

However, a word of caution. If you go crazy with these, you may find you have too many workflows and actions within workflows to manage. It’s best to think of it like candy. Every once in a while is fine, and can make you feel happy for a bit. But too much too often can make you regret it before too long!

As always, don’t forget to subscribe to be notified by email of new posts! You’ll find a signup form at the bottom of the post. Also don’t forget to check out our Atlassian Discord Chat! It’s still ramping up, but I’m always happy to see people getting questions answered there! https://discord.gg/mXuRsVu

But until next time, this is Rodney, asking “Have you updated your JIRA issues today?”

Creating a Custom Workflow

Rodney N.1 Comment

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:

It’s a bit spaghetti, but it works!

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?”