Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

Workflow Category

Can anybody tell me what the workflow category does, apart from change the colour of the box? Does the workflow cetegory determin any permissions for the status? If so where can I find them?

3 answers

1 vote

To my knowledge, its just to group your records based on the colour code (Categories). I think permissions are not connected to this. 

Hi, Vishnu, that is my understanding too. Somebody here said they thought that some permissions (booking time, in this case) were dependant on the workflow status category. I am far from being a JIRA expert so I thought I would ask the question. 


Thanks for taking the time to answer.

Like Bala_Subramanium likes this

I haven't seen it connected any where till now. Thought it's just a color flag which will tell you whether the task is " To be Done" or " In Progress" or " Completed". 

Like Evert Penninckx likes this

There are no permissions connection to the status category. (You could write an add-on to provide them though.  I'm not aware of any that do it in the marketplace)

It can be set up to look like it - we often put "do not edit" flags on status that are in a green category so that people can't update closed issues.   That looks like "green = no edit", but it isn't, it's just that we've applied it to the green status.

Thanks for clarifying it Nic. 

I would change all queue states to "To Do" -- essentially if you want to divide working/waiting/done, to do is a waiting state, just like the other queues. Ideally you'd have a set of statuses in which To Do is before its ever "begun" and a new waiting category ("queue" or similar) to differentiate "In Progress" states to show how much time an in progress item spends actively being worked versus queueing.

The Status categories are the status groups for you statuses... ha... 

the default are ToDo, In Progress, and Done.

In the columns view of a sprint, they align wtih those status categories.  However, if a ticket is changed to "done" or a green status, it will disappear from the colum view.

I want to know how to add a new category status?  I know you can do this in the column configuration, but how to i get those new colums with the new category to show up in my workflow, so i can change statuses to align with that status category? 

For example, If i have a status that says, "ready for deployment", i dont want it in in progress, bc technically it is complete, and if i put it under "done" it will disappear from the column view, thus assuming the task has been completed and there is nothing else to do with it. 

Does anyone have any insight? 

The three categories are pretty much hard-coded, so you'd need to go digging into the core of JIRA to add one.

I'd check your board filters carefully, as you say your issues "disappear from the column view", it suggests your filters are hiding them from the board.

Like Patrick Nelson likes this

I wonder if it's the "resolved" state... let me check that out.  Thank you for the tip.


It's quite common to do that.  It does make sense, and it does work, but it usually needs a bit of explaining to users as some will ask why their cards vanish.

The trick is to have a board filter that says something like "and resolution is empty".  This means you still have a "done" column to drop your cards into when they're done, but the act of doing that sets a resolution and hence the card becomes de-selected by the board.  It is neat and keeps your done column clean without losing it, so people still have somewhere to drop the done cards.

However, if it's confusing, it might be worth a tweak - instead of "and resolution is empty", try something like "and ( resolution is empty or updated > -7d)".  This would mean cards that are resolved/done remain on the board, but after they have not been updated for a week, then they get de-selected and disappear.

Personally, I would change all queue states to "To Do" -- essentially if you want to divide working/waiting/done, to do is a waiting state, just like the other queues. Ideally you'd have a set of statuses in which To Do is teh category that reflects wait that happens before the work is ever "begun" and a new category ("queue" or similar) is added to reflect wait that happens after the work "began". This allows us to measure efficiency of work in process: how much time an in progress item spends actively being worked versus queueing.

Like Lara Bailey likes this

I completely agree. I don't understand why there's only three categories and not four, for this reason. 

Because the suggested queue category is the same as to do or in progress depending on your process. It is too vague to be useful and not needed.

There are 3 status categories in JIRA - 'To Do' (blue), 'In Progress' (yellow) and 'Done' (green). 

Any new statuses that you create [for use in your workflows] will be mapped to one of these core categories and will take on the same colour. 

The colour coding helps when configuring your workflows and mapping your statuses to the columns on your boards.

It also helps users to identify where issues are in their lifecycle.


So, if a status is Green for DONE, it does not drive any action for the issue?  In other words, if I wanted to create another mini-process AFTER a story has been accepted (with a category of DONE), I can do that??


Yes, you can, it's all about the workflow.  The three categories really are just logical groupings of status that doesn't do much in itself.

They do - they are used to track total time spent in each category. All Todo categories are summed up together, as are all In Progress and all Done. The issue is there needs to be a 4th category for Waiting, so we can track time a project is waiting as well. Todo should be separate as it's not waiting for anything except resources, which is important to track as well, but distinct from waiting for something outside of the team's control. 

So it means "in progress" to you.

The reporting you are talking about is something that should be being done at the status level.

Suggest an answer

Log in or Sign up to answer