Is it possible to restrict workflow status options based on Issue type?

Hello all,

I'm new to Jira and Atlassian products in general but am impressed so far.

After much research and seaching I have a question, though. Is it possible to restrict workflow options based on an Issue type?

E.g., someone creates a new issue with type "Detail Required" and it has a workflow option of being moved into "In Progress", but if someone does the same action (creating a new issue) except with type "Bug" the workflow option is "Awaiting Review".

In the workflow creator both items would start with the "Open" status as the issue is created, but the actual path of the issue ought to vary depending on the issue type.

Does it make sense to use workflows in that way and, if so, could someone share how to restrict the workflow based on Issue type?

Many thanks!


3 answers

1 accepted

1 vote
Accepted answer

Hi Brock,

Have a look at this thread:

Here I describe how you can take a different workflow transition, based on a due date value in this case. Of course you can reuse this example for issue type values.

In your case I would suggest you have a look at transition conditions. A condition decides if a transition is shown in the issue or not at a certain point (the transition button on top of the issue view). If the condition of a transition returns true, the button for that transition will be shown. Else if the condition returns false, the transition will not be available. Since you can start from the Open status I would suggest the following:

1) Create a workflow that has 2 transitions leaving from the Open status:

a) The first transition will lead to the 'In progress' status. Add a condition to this transition (named 'Value Field'). Select the Issue Type field, condition = and value Detail Required. This transition will only be visible (and available) if the issue type is Detail Required.

2) The second transition will lead to the 'Detail Required' status. Add again a Value Field condition to this transition with the following parameters: Issue Type field, condition = and value Bug. This transition will only be visible (and available) if the issue type is Bug.

Hope this is the answer you were looking for! Feel free to comment if you get stuck...

If you really have complex workflows and different paths for diffent issue types, it is best to work with Workflow Schemes:

They keep your workfows much simpler. In your case I would suggest to use different workflows for the Bug and Detail Required workflows and define the mappings in a workflow scheme.


Thank you VERY much for your prompt and helpful responses! What you describe above is exactly what I am trying to do.

I am wondering if I am looking in the wrong place to add a condition to a transition (the same goes for adding validations). I only see a preset list of potential conditions and no option for a custom condition.

I access this list via:

Transition>Conditions>Add condition

Is that the proper place to add a custom condition?

Thank you VERY much for your help.


It sounds like my strategy of a "master workflow" is probably not the right way to do it. I was thinking that you create the whole flow in one workflow and then apply conditions, validations, and screens as necessary to make it easy for someone to use the workflow. Instead it sounds like I should be creating independent "mini workflows" that track the path for each issue type (or group of issue types that share the same paths) and then map those workflows/issue types via a scheme.

I don't know that the workflow is too terribly complex, though.

That's perfectly fine, but I definitely want to follow the best practice on this that will result in a useful flow for our folks.


Sadly it looks like you've helped me identify the problem - customized conditions and validations aren't available on Jira OnDemand. :(

Thank you very much for your prompt and helpful replies!


PS If you want, feel free to post this and I'll mark yours as the answer so you can grab some karma points. :)

Hi Brock,

The way I see it:

1) Every transition that starts from the 'Open' status has to be converted to a separate workflow (f.e. Icebox workfow, Awaiting Review workflow and In Progress workflow). Feel free to find better names :-). You could have guessed that this will introduce some redundancy, but the advantage of having simpler workflows is much more important here.

2) The next step after workflow creation is defining a workflow scheme. In this case you will have 3 different issue types, I guess. So make a workflow scheme that does the following mapping:

a) Icebox issue type -> Icebox workflow

b) Awaiting Review issue type -> Awaiting Review workflow

c) In Progress issue type -> In progress workflow

3) It is also really important that you foresee a default workflow for the other issue types. So also add the following mapping to your workflow scheme:

a) Unassigned issue types -> classic default workflow

4) The last step is attach the workflow scheme to every project that has to use it.

Conserning the use of Jira OnDemand. It is true that this version has a lot of limitations regarding custom javascript, installing all plugins,... By making use of workflow schemes instead of conditions and validators, you should not run into any restrictions.

Hope this helps!

And of course the start node, the issue created transition and the Open status are part of every workflow :-)

0 votes
Joseph Pitt Community Champion May 12, 2014

each issue type can have its own workflow as well as screens and fields. For select type custom fields you can configure them to have different value options based on issue type or project. Set aside 2-3 days to completely review the documentation.

Thanks Joe, I appreciate the response. I have spent about 30 hours or so going through Jira and the accompanying documentation and am familiar with the operation of screens and fields, but it sounds like I may have been thinking about workflows backwards.

I had been thinking of a project's workflow as the master guide to all work on the project - put all your statuses, transitions, conditions, validations, etc. into a single workflow and then design screens to aid in the transitioning of work items through the workflow.

Per your comment it sounds like that is incorrect and the better way to think about workflows is an Issue Type-specific workflow overlay (like a screen) that is created to support work on particular types of work items.

Is that correct and, if so, does that mean a well organized Jira project will NOT have a "master" workflow that you can look at and see how every issue type flows through the project?


That should work perfectly - thank you again for your help!!


You are welcome. Brock! Glad I could help! :-)

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,653 views 18 21
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