Can you create parallel steps in a Jira workflow?

[KevDog]

Three departments need to sign off on a project step, is there a way to construct a Jira workflow that makes this possible?

[Alex Christensen]

A single issue can only be in one status at a time. If you need more than one status at a time, I generally recommend having more granular tasks to track multiple statuses.

You could set up a workflow using sub-tasks for approval. You might follow this scenario:

• The parent issue is the task that needs to be signed-off.
• At a certain point in the workflow, create three sub-tasks - one for each department to sign-off.
  • With add-ons like Jira Misc Workflow Extensions, you can even automate the creation of these three sub-tasks so that when you enter a certain status, these three sub-tasks will always be created at that time.
• The parent issue should not be able to be closed until all three sub-tasks are closed (i.e. sign-off is completed).
  • With the same add-on as above (and others like ScriptRunner), you can also automate closing or transitioning the parent issue to another status once those three sub-tasks are all completed/resolved.

[Paul Wright]

Great approach.  I implemented this today and the sub tasks create automatically (as a post function), auto assign to the correct team and individual (using field ID instead of names), the right people get notified and the process uses automation to move the ticket through the transition steps as items get approved (or declined).

I had lost some sleep trying to think of a way to get this to work, so your idea was definitely an inspiration.  It is frustrating that there's always 'an add on for that', and this proves that outside of the box thinking and sharing in forums makes us maximise the application and not the price!

I also created new sub task types (called 'approval') that has it's own screen scheme and workflow.  It was worth the effort.

I've installed an add on too (freebit), to colour code the buttons (green is good, red is bad), which really helps.

I'm giving the stakeholders a demo later this week.....fingers crossed!

[Nick Read]

Hi @Paul Wright - how did you get on with this? Looking to do something similar and wondering if it's worth the effort.

[Paul Wright]

Hi @Nick Read   It certainly was worth the effort, and after a few attempts at getting the logic right it wasn't as difficult as I initially thought.

The approach I took to make the Issue Type a new Issue Type so it was completely independent from other workflows, with it's own custom fields, but still a part of our main project.

I also created new sub task types within the project that had independant workflows associated with them.

When the main Issue Type is created, automation creates some initial sub tasks that are 'default'.  The Summary, Description, Categorisation, assignment etc. all autofill.

During the workflow, once the issue type is 'ready' to move forward additional sub tasks are raised (the newly create sub tasks with independant workflows) and these have the approval stages.

The primary ticket cannot progress until the status of the sub tasks is in a certain stage, using the conditions logic.

I had used this approach before, but not to this extent - the approval piece from different departments was really critical to the workflow.

We end up with 5 different areas for approval - each works their own ticket at the own pace.  It works like a dream.

I've not automated the primary ticket's automation to progress when all approvals are given, but that's a personal choice.  It's sometimes a balance between keeping it simple, and staying 'engaged' with the process.

I did have another win during the build of this - I found a free add on that allowed me to colour the buttons, so approvers can clearly see their options "Approve" and "Reject".  It's a simple win, but the feedback is really positive.

https://marketplace.atlassian.com/apps/1216222/alkaes-field-administration-enhanced?hosting=server&tab=overview

Good luck with your project!

[Virendra Kumar]

how do you create sub-task types?

thanks

[Paul Wright]

There's lots of great advice out there on the forum on how to create tasks and sub-tasks (one example: https://confluence.atlassian.com/servicedeskserver0412/creating-issues-and-sub-tasks-1026033802.html) 
You may need to create a new screen schema for the sub tasks if you want to use different fields and workflows will need to be interdependent if you want to get this process separate.

[Nir Haimov]

does the project workflow requirement represent as an issue task for you to do?

You can do the following:

1. Create 3 checkbox custom fields
2. Create 3 transitions from a status to itself

Finally, with workflow condition, you can make each transition button to appear to the relevant department.

Once a department click on the transition button, it will mark the checkbox (for you it means they sign on it), once they sign you can disappear the transition button, as they do not need to click again.

Hope that's what you wanted in the end.

[Mykenna Cepek]

No Jira add-ons are needed to perform the general steps discussed here:

• Create sub-tasks on an issue (automatically, or with a manual step)
• Automatically close the parent issue when all the sub-tasks are closed

Jira Automation can do these steps, with or without a special Issue Type. If you must have a separate workflow and/or customized fields, then a special Issue Type does make sense.

Otherwise one could rely on a different convention (Summary prefix, Label, Component, etc) that automation rules can detect (instead of a special Issue Type)

Instead of using sub-tasks, checkboxes can be used (and checkbox support requires an add-on). What I'm suggesting here requires an add-on which additionally supports Jira Automation. I've used checkbox add-ons which allow lists of checkboxes to be added to issues by an automation rule, and allows rules to query to see, for example, if all the checkboxes are completed.

The Jira Marketplace has many awesome add-ons. And some Jira users are very cost-sensitive (as most awesome add-ons cost extra). I want to ensure folks realize Jira Automation (a built-in feature of Jira) can handle most or all of the use cases discussed here.