Tag: workflows

App Review: JIRA Workflow Toolbox by Decadis

Rodney N.Leave a comment

JIRA Workflows are the backbone of the system. They dictate how issues flow, who has what responsibility, or when you need to do specific tasks. Do you want to start a fight as a JIRA Admin? Just tell a user you are changing their workflow without their input.

That is why I decided to look at the JIRA Workflow Toolbox by Decadis for the third App in the “App Month” series. And when I started, I thought this was just another collection of validators, conditions, and post functions – not dissimilar to JIRA Suite Utilities and JIRA Misc. Workflow Extensions. But I soon discovered that this one App has the power to displace two or three Apps in your system. All for the cost of one.

Now, I want to take you through the features I discovered, and let me tell you why you should consider this App!

Features

So, I should apologize to Decadis. They were gracious enough to meet with me one on one to give me a demo of this App. And what was my first question? “What do you think sets you apart from Apps like JSU and JWME?” Not my proudest moment.

However, When I first sat down with this App – that was my main question! I had heard good things about it, but to me, it seemed like a clone of sorts. My error: I skipped over the Getting Started page. Seriously guys and girls, don’t be like me. Be better than me!

Also, read your docs before opening your mouth!

If I had taken the time to do my research and read this page, I’d have found that the workflow functions were just one facet of this hidden gem. So let us take a look together at the other functionality this Multi-tool has!

Workflow Functions

So this is where the App gets its name – and likely what you will be using the most. As I stated earlier, this is where I started looking – and if you are like me, you might find this very familiar. Many of these are post functions, validators, and conditions you will find in tools such as JWME and JSU.  

You can find the usual assortment of post functions (add comments, manipulate fields, create an issue link), but you can also find some more exotic functions like move an issue. This feature can be especially powerful to change an issue type mid-workflow based on a field value.

In speaking of field values, the post functions for JWT has a functionality that I don’t think I’ve seen with any competitor – and is a bit of a game-changer. You can add a condition to an individual post function to control when it executes. Let that sink in. You can have a single post function not run based on values in the fields or properties on the issue.

Having this ability opens up some exciting use cases. You can have multiple projects use the same workflow, but have each project run a unique set of post functions in a given step. Or you can have the workflow move the issue to a high-priority issue type and workflow if it sees fields set in a particular way. This functionality is some potent stuff!

Automation Rules

That’s right; there are Automation Rules bundled in! The setup here will also look familiar if you have Automation for JIRA. The similarity is more an example convergence than copying, but there are unmistakable similarities.  

My understanding is that this used to be its own unique offering, but after Atlassian bought Code Barrel, it was only logical to combine the offerings. However, if you don’t have Automation for JIRA, this can be invaluable to you.

Automation is one of the key ways people try to work more efficiently in JIRA, and this is a great way to gain an automation capability if you don’t have one. Having this capability in the App is a sweetener on this deal. However, there’s more!

Calculated Fields

So, personally, this is my favorite feature. Before, if you wanted a derived field – that is a field you calculate from other fields – you would need Scriptrunner. And these sorts of calculated fields can be rather powerful.

For example, I saw a question recently where someone wanted to know how they can sort our customers based on their email domain. This kind of parsing and sorting isn’t possible in JQL.

However, using a calculated field with this expression, we get a field that automatically generates the desired domain.

findModify(%{00007}, "(\\S+@)", "")

I will note that this is currently using the field ID number – not the field name. There are plans to change this soon! But in the meantime, they do include a handy string injector, so you don’t have to go looking up field ID numbers.

This example is just one use case I can think of. You can sum up the story points of related issues, or pull information from a parent issue in real-time. The possibilities this allows are near limitless. This feature is an MVP in my book!

UI/UX Changes Ahead!

So, you might have noticed the lavender elephant in the room in my screenshots. Their current User Interface features this table of purple boxes. While not a deal-breaker – I have seen MUCH worse – it can be distracting. Decadis admits as much, and to fix are about to release and end-to-end rework of their UI.

Another part of this is they will also be reworking their parser to do away with the need for you to know your field ID. In other words, they will be able to take the field names within the App’s various functions.

And while I’m on the topic of UI/UX, I mentioned in my review of the Admin Toolbox that the categories should be renamed to make them less confusing. It is something they were already working on, as during the demo, I spotted this!

Not really related, but I thought it was a nice touch!

My Analysis

What this App does Well

So, let me be straight with you. For each of the things this App does, I can think of another App that does it equally well (if not better). That is not to say that this App is terrible, quite the opposite. It takes a serious commitment to quality and user experience to compete in those lofty circles.

However, I think the real value proposition is that this one App does all three functions. Just going to level with you, Marketplace Apps are expensive. There is a particular pain that comes with that annual P.O. to renew Apps. So saying you have this one App that can do multiple things starts to look attractive.

And then there is this to consider. My feeling in reviewing both this App and Admin Toolbox is that Decadis cares about making your teams their most efficient selves. Every feature seems tuned to that end goal. And honestly, I think they easily hit that goal.

What this App could work on

So, I honestly had a problem with this section. Most of what I originally had originally intended to say here, Decadis showed they were already working on! But honestly, there are worse problems to have!

However, there is always another horizon to conquer. That is to say that I feel we can always improve something. To that end, I do have this (I’ll even put this in a user-story format).

As an Admin, I would like to migrate easily from JWME/JSU to your App.”

The JIRA Guy, 2020

To pull this off, you’d need to almost reverse engineer how the other Apps store their data and then create a migration script. It’s not an easy goal, but if Decadis can pull this off, that’s a goal worth celebrating.

Would I recommend this App

This point is another section of my analysis where I struggled. It’s not that I don’t love the functionality this App provides, I thoroughly do! It’s more that my recommendation is going to be somewhat conditional.  

If you don’t have Scriptrunner, Automation for JIRA, or a Workflow Functions App, go for it. You will be thankful to have the extended functionality this App provides.

If you have any or all of the Apps I listed above, you should take a more in-depth look. 

  • Are you using some of the other functionality of Scriptrunner, or are you using only the Calculated Fields?  
  • To what extent are you using Automation for JIRA, and whats the effort in migrating those rules?  
  • How many person-hours in migration are you going to spend versus how much money on the bill you will save?  

Simply put, the answer is going to vary significantly from organization to organization. I’d still recommend you at least take a look at it.  

JIRA Workflow Toolbox’s Tier Rank

So where to place this one wasn’t a difficult decision. This App is yet another robust offering from Decadis, and easily earns it’s “A” Tier. From the conditionals on the post function to the Automation Rules and Calculated fields, Decadis designed this App to make life easier. You wouldn’t go amiss to check this one out!

And that’s Week three of App Month down!

So, are you digging the flurry of new Apps reviews? It certainly looks like you are! I have two more to write up this month, and I am looking forward to diving into both of them!  

In other news, I have been asked to give another Webinar, this time by WebGentle! For this one, I have opted to present on one of my favorite articles to-date, “So, you’re now a JIRA Admin, now what?” We will cover steps you should take your first week as a JIRA Admin to set you and your instance up for long-term success. The webinar will be on Thursday, July 23, at 10:30 AM EST/8 PM IST. You can register using the link below to attend! I hope I get to see all of you there!

  • Register to attend Webinar

Future Rodney here! The Webinar is already one. But fear not, you can view the YouTube video for it below! Now back to our regularly scheduled post!

I also wanted to get your thoughts on something. How do you capitalize JIRA? I still put it in all Caps – it’s an old habit, and not 100% accurate, but it’d take me longer to change it all to normal on this site than it’d be worth.

However, I want to know what you readers think. So I’ll be putting a poll in the article, and keeping it open for two weeks. If enough people vote Jira, I’ll start using that here forward.

But that’s all I have for this week. Please remember that if you liked this post, please like, comment, and share it on your preferred social media platform. If you loved this article, sign up below to get new posts delivered straight to your mailbox. You can also follow me on Twitter, Facebook, and LinkedIn! But until next time, my name is Rodney, asking, “Have you updated your JIRA issues today?”

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

Using JIRA For a Job Search…well…that’s a thing.

Rodney N.2 Comments

So, I’ve been quiet here for a bit. There’s a reason. At the end of July, I was laid off. I’m told it had nothing to do with my performance, that is was just a matter of us loosing a major client and the numbers not adding up.

Either way, that puts me squarely back in the job market, which has been my focus for the past month. However…

The JIRA Angle

The thing about a job hunt is – you gotta keep on it. It’s on you to follow up with an HR representative and figure out whats going on. Don’t be pushy, obviously, but be engaged. To that end, it was quickly getting to the point last week where I couldn’t keep track of all of it in my head.

Job hunting is also a project – and I happen to know a good deal about a highly customizable Project tracking tool. So, I fired up my personal JIRA instance, patched it up to 8.3.1, and created myself a new project: JobHunt (JOB)

This was a custom project from the ground up. It was as much a task to keep my skills sharp as it was to solve a practical problem. But I’ve also realized it’s a great way to show just how flexible JIRA really is. So I’m going to break it down for you, so if you also would like to do something similar, you can.

Workflow

This project uses a simplified workflow. The reason I chose that style of workflow is simply the fact that it isn’t a terribly complicated affair. I don’t have to show parallel work on my end per application/recruiter, so there isn’t a need for subtasks, but at the same time I’m not trying to do automatic reassignments. Basically, a simplified workflow allowed me enough flexibility without becoming a burden.

Each status is a step in the process. As usual with such workflows, I like to use the past tense, with each issue in the project moving to that status when the appropriate condition is met, such as I’ve completed a phone screen with a given Recruiter or HR department, I’ve done at least one Interview with a given company, etc.

I understand this can probably be refined further, but the best way to see those refinements would be to use it, and in the past week of use those possible refinements have yet to reveal themselves to me.

Screen and Fields

The Screen and fields have a number of custom fields that I’ve added to the project to help with retaining pertinent information on each position. In detail they are:

  • Company – Single Text Field – This is fairly self explanatory…it’s the company the position is with. In cases where it is a recruitment firm on behalf of another company, I’ll put this in the format of “Company (via Recruitment Company)”
  • Description – This is where I’m storing the Job Description. No need to create a new field when one is serviceable.
  • Job Location – Label Field – This is a label field describing where the position is located. This saves me on retyping, as the location is usually only a handful of possibilities, but lets me add more on the fly without having to modify the field or reindex
  • Job URL – URL Field – A URL field for a job listing so I can refer back to it later. It’s more of a “For your reference” field, and normally wouldn’t make the cut for my criteria for a custom field, but it’s saved me a lot of re-googling.
  • Job ID – Single Text Field – a Field for storing a job ID number. This is helpful if I am contacted by mutliple recruitment agencies for a single position.
  • Recruiter/Contact – Single Text Field – Okay, so confession time, I often have a hard time remembering names. So – put a field for it. Then I can remember it was Sarah that I was speaking to about that position at that one company.
  • Contact Phone Number – Single Text Field – places to remember the number for my Contact for a given position. It’s also meant to cut down on looking up information.
  • Contact Email – Email Field – Does the same thing as the line above. If possible, I’d prefer an email rather than a phone call, so I usually give priority to this field
  • Last Contact – Date Field – When I last heard anything on this position. This is useful for knowing a) when to reach out to a contact about a given position, or b) when to give up on a position should I not be contacted at all about it.
  • Rate – Single Text Field – Simply put – what I’ve put down as my desired pay for a given position, or what the company is offering.

A note here, On all but the most intuitive of Custom fields, I’ve added a descriptor text. This is always a good idea, as even though it may be clear to you right now what a field is for, it may not be as clear to a user. Because this is my personal instance, I was a little more informal here than I would be on a corporate Production instance, but even then I still felt the need to be consistent with using them.

Dashboard

The Dashboard is a rather simple affair with four gadgets. Starting in the Upper Left, we have a Created vs Resolved gadget, then two Filter Result Gadgets, and then finally a two-dimentionsal Filter Stats Gadget. These are powered by three Queries. The first one is a simple query, which gives us everything not listed as done in the project.

project in (JobHunt) AND status not in (Done)

This is used on the two left most gadgets. The thinking here is the only time I care about one of these being done is when I accept a position, which would invalidate the whole reason for this project to exist. As such, beyond noting why I didn’t get a position, it doesn’t need to be on my radar, and thus I let it fall off my Dashboard.

I use the Created vs Resolved more to track how many positions I’m applying to each day. I’d like to apply to at least one per day, so this is more for personal goal tracking.

The Two dimensional Filter stats gadget is more for personal reference. I obviously want as many positions to move forward as possible, so this helps me see where they are as a group and encourages me to keep checking back on the various positions.

The second query is to list those that I need to reach out to.

project in (JobHunt) AND "Last Contact" <= startOfDay(-7) AND ("Contact Email" is not EMPTY OR "Contact Phone Number" is not EMPTY)

Basically, what this is doing is returning every position I haven’t heard back from in the past seven days, but only those that I’ve listed a contact phone number or email address for. It doesn’t help me to try to reach out to someone who I don’t have contact details for, so this is to help the list remain relevant.

The last query I use on this list is those I’ve applied to in the past seven days.

project = JobHunt AND createdDate >= -7d

This is again to help me visualize my goal of applying to at least one job per day. Now I don’t actively search on the weekends, but there are days I do get more than one position, so the average is usually better than one a day including weekends.

The Kanban Board

The final piece I want to look at is the Kanban Board. It’s fairly vanilla for the most part, with one column per status in the workflow above. The two areas I customized it, however, are two that don’t get alot of attention: the Card Layout and Card Color.

For the card layout, I wanted to be able to see the relevant information at a glance. As such, I’ve put the above three fields on it – Who is it with, where is it, and when was the last time I heard about it. This maxes out the card, but the Summary already answers “What it is”, and the “Why” isn’t something that will fit on a card anyways.

I also decided to use the card colors to help me identify how long it’s been since I heard back on a given position. This is more an aesthetic choice, but it does help me know what’s good and what’s in trouble.

Final Thoughts

So – I don’t know if this is going to help me in the long run – but as a JIRA Admin, I do need to keep my skills sharp, so it at least does that. I’m going to try to post here more often, with my next post going to be on how to install JIRA to a clean linux instance. Until then, I’m Rodney, asking “Have you updated your JIRA issues today?”

Workflows, huh, what are they good for?

Rodney N.1 Comment

Intro

Oh workflow, oh workflow, wherefore art thou workflow?  This is probably the least understood part of JIRA.  For example, here are just a few of the questions I get nearly weekly here:

No, Seriously…I get asked thse alot….

What is a workflow?
Why do I need it?
What can it do for me?
What can’t it do?		Which one do I pick?
What are my options?
Why can’t this be easy?

Needless to say, there needs to be some clarification on this subject matter – hence why it the first blog post I’m writing is about this.

What is a workflow

The workflow – to put it simply is the steps, or statuses that an issue travels through.  You can often see them displayed as such below.

These two are examples of a Simple and Complex workflows, respectively.  We’ll go into detail about what makes each what it is in a moment.  In this representation, each status is represented by a candy bar – with the issue’s current status being filled in. The circle in each is meant to signify the issue creation, and the arrows represent transitions between issues.  Please note that the first transition – from the circle to the destination, happens automatically when we are creating an issue.

Simpliflied Workflow
Complex Workflow

You can also note that each status has a color.  These are standard in JIRA – and we have no ability to change them.  Blue is meant to signify a start or backlog status, Yellow meant to signify an “In Progress” state, and Green meant to signify the end or termination state.

Basic parts

As shown above, there are two basic parts fo the workflow: Status and Transition.  Statuses are the boring part – they are what they are.  It’s meant to signify what “state” the issue is in.  For complex workflows, I like to make the status show what it’s waiting on, hence why they tend to be something like “Pending X” or “Waiting on X”.  The transition is where the action is, however. During transitions, you can have it automate certain actions – like reassigning the issue or updating fields.  We’ll go into further detail about this in another section.

Simple vs Complex

As stated, workflows can be classified into two general categories: Simple and complex.

A simple workflow is just that.  It only has three to four generic statuses, and each can be transitioned to from any other status (Marked with the “All” transitions above).  The purpose of these is to support teams who do a variety of tasks throughout the day.  The thought is your team will define the steps to completion using sub-tasking, and each sub-task will travel through these generic steps.  This also allows you to show parallel work – something a complex workflows cannot do.  In general, this is my advice for most teams.

A complex workflow is in many ways the opposite.  It has single status-to-status transitions, and more nuanced statuses.  This is great for highly regulated tasks, such as the requisition flow shown above.

In general, I advise the use of simplified workflows when possible.  They are much more adaptable should you decide to change how your team works.  With a complex workflow – any such changes will require you to work with a JIRA Admin to change the workflow appropriately.  However, for workflows that need tight controls, a complex workflow may be required.

Conditions, validators, and post functions

The Transition is said to be where the action happens within the workflow.  That is because there are three parts to the transition – the Conditions, the Validators, and post functions.  There is also the ability to display a screen to gather information relevant to the given transition.

Conditions tell the system when and to whom to display the transition button to.  If you cannot see the transition button, it is likely because some condition isn’t satisfied.  While a useful guardrail to prevent people from transitioning an issue who aren’t supposed to – it’s often confusing because you don’t get an error text – you just don’t have a button.

A Validator is similar to a condition in that it evaluate whether a transition can occur, but it happens during the transition.  It is useful to make sure people have filled out information appropriately – and is often paired with a pop-up screen (but doesn’t have to be).  Validators are often more useful as they do return error messages – making them ideal to make sure fields are filled out correctly.

The Post Functions run after the Transition occurs, and allows you to change fields within the function.  This is often how “Automatic Reassignments” are done within JIRA – by attaching the appropriate post function to the correct transition.  It should be noted that certain post functions have  to occur for JIRA to work properly – and therefore a JIRA Admin is required if you want to make any changes to post functions. 

Within every transition – there is a order that the operations occur:

Order of Operations

1) Conditions evaluated to see if user can use/see transition
2) Transition button is pressed
3) Screen is popped up (if set to)
4) Validators are checked
5) Issue is transitioned
6) Post functions are run

Now – the biggest request I get is to have JIRA make decisions in the workflow based of the issue of fields.  This is technically possible using conditions – it is not advised.  The reason why is this will lead to what’s called a “Spaghetti Workflow”, which is often confusing for end users, causes admin headaches when changes need to be made, and a in general leads to a lack of adoption. 

Termination – Resolution vs Status

If there is one thing I consider a cardinal sin within JIRA, it’s this:

This is an issue I see a lot, where teams will want to have multiple termination states to describe how it was closed.  This is not how JIRA is meant to be used. The idea is to assign a resolution describing how it was closed, and have a single termination state to show that it is closed.  JIRA, in fact, will not consider an issue closed until it has a resolution.  So when you are coming up with a workflow – please keep this in mind.