On the usage of JIRA workflow status and steps


today I got a bit confused on the usage and benefits of JIRA workflow steps compoared to status. While it is clear that I can only use steps in workflows I don't quite get why this is needed and, more important, how can I benefit from this. Even the DOC says it is best to name both elements identical, so where is the use of this?

I had a use case this week where I wanted to assign existing status with different values for the step. This works well, but I only later noticed that the view issue screen shows the global status and not the mapped step. The reason why I used different naming conventions was simply to not have too many statuses in my JIRA and therefore to not confuse users to not know which status should be used in several JQL queries. So in the end I want to keep my existing set of statuses whilst displaying the step name to the user.

So this makes two questions:

1) How can I (as a user/admin) really benefit from status vs. step?
2) How can I achiev the mentioned scenario?

Thanks and regards,


1 answer

1 accepted

2 votes
Accepted answer

Think of the steps as a skeleton to hang the rest of the workflow on. Also, forget them, from the users point of view, they don't really see them, they see Status. That's a (Translatable) label you can apply to show the user what step they are on.

I know it would seem more intuitive to throw "step" away and just say "choose your list of status, then add transitions", but it's actually quite painful to work that way. Having steps and status separately gives you more flexibility (and hence, complexity, as there always has to be a down-side)

Hi Nick, thanks for your answer and sorry for the late reply.

While I agree with the idea to just "throw away" steps at all (but we cannot do that obviously) I now have to keep names of status and steps in sync in order to not create more confusion for our admins. Again this brings me back to my initial two questions:

1) How can I avoid having too many global status but still using compltely different "contexts" for my project (think of dev vs. administrativ vs projekt management vs HR...). They all need their own status (at least partly) and the issue navigator (and taskboar/RapidBoard in Greenhopper) is cramped up with all those different status which no one understands apart from me.

2) Where is the reason for still having steps? (I know this one should be rather directed at atlassian...)

1) You can't. Get your users to shorten their list of status. In the issue navigator, that only lists status that are valid for the currently selected project.

2) Yes, that's for Atlassian. I've worked on other workflow engines though, and the ones that don't have a skeleton are an absolute nightmare to rename, edit, internationalise, and so-on. The editing looks easy, but it really is a pig.

Suggest an answer

Log in or Sign up to answer
Community showcase
Published Nov 27, 2018 in Portfolio for Jira

Introducing a new planning experience in Portfolio for Jira (Server/DC)

In the past, Portfolio for Jira required a high degree of detail–foresight that was unrealistic for many businesses to   have–in   order to produce a reliable long-term roadmap. We're tur...

2,420 views 15 19
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you