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?
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:
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. :)
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.
Hope this helps!
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?
Hey everyone! My name is Sarah Schuster, and I'm a Customer Success Manager in Atlassian specializing in Jira Software Cloud. Over the next few weeks I will be posting discussion topics (8 total) to ...
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!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
We're bringing product updates and pro tips on teamwork to ten cities around the world.Save your spot