How to manage many similar workflows?

[Artemy Matvienko]

I have multiple projects that use variations of the same base workflow. The variations depend on the requirements of the project or issue type. The variations mostly come in the form of new statuses and new workflow transition post functions. This creates a problem where the base workflow gets a modification that needs to be applied to all of the variations as well. As you might imagine, this can be time consuming and dull to do manually, especially since the test versions of the workflows need to be updated as well, which effectively doubles the workload.

To be more specific, the software development general workflow in question includes the development, support, and QA teams. One of the requirements is to be able to track how much time is spent by a team to do their part in resolving an issue.

Some nuances to consider:

1. some issues may be put on hold due to other priority items and would skew the time tracking results as no actual work was done on the issue while it was on hold.
2. similar to the on hold statuses for the two departments, there are "transitional" statuses in the workflow that serve to show that the work has been assigned but was not yet started.
3. we found a free time tracking plugin that goes off of the amount of time an issue was in a certain status with a certain assignee. It eliminates the need for users to manually input their tracked time through the OOB time tracking. This was the main force behind adding a lot of statuses to keep the time tracking as accurate as possible.

Are there any solutions to this use case to make the workflow modifications more modular and less manual/time consuming? Maybe with the use of some plugins or creative restructuring?

[Pete Singleton]

Unfortunately not, just because the workflows are similar there is no actual link between them.  So any changes you need to make need to be applied to all.

[Gary Pasquale]

As above, the workflows are single entities.

I think the key here (as we've found out the hard way) is minimising the number of custom workflows. Getting teams of a similar function sharing workflows where possible.

Not being too restrictive, but given teams a choice of some predefined workflows to choose from. Any future changes must then be agreed across those who share the workflow.

[Artemy Matvienko]

Would you say that "outsourcing" certain functionality from the workflows into custom fields would be a more flexible idea? Instead of having a custom status for "to be integrated" you could have an "Integration" field saying "Pending", while keeping the issue in the "in progress" status, for example? This would allow a workflow to be more flexible and any post functions can reference those fields instead of relying on placing the post functions in the new statuses. Those functions would also check if the field needed for the processing exists in this context, if it doesn't that part gets skipped. That way all related processing can go into the same "conditional" post-function script, instead of having different versions of the script.

The idea behind this approach is to relocate the varied automation and issue customization into something more flexible. Although I'm not sure that fields and screens are necessarily more flexible.

I want to have some alternatives to capturing the data that the workflow statuses currently capture for reporting purposes to satisfy the requirements of the management team.

[Gary Pasquale]

Using custom fields, labels or components as other ways to identify the status of an issue seems like a sensible idea. But that cause other issues. Increasing your number of custom fields for one.

Having a post function that checks a custom field still makes that workflow 'unique' in some way. Workflow's with conditions and validations won't work on projects that don't have that custom field (Post functions may be more flexible). That will limit how widely that workflow can be shared.

[Artemy Matvienko]

We don't really use conditions and validators. Most processing goes into post functions and behaviours. I'm thinking of having something like a "sub status" custom field. It would contain extraneous statuses that we currently have polluting the workflows like "to be integrated, "on hold", and various stages of QA.

I think the workflows currently are indeed too customized, even though they clearly share a base which could be used instead for much greater consistency and version control. I often have to add new statuses or pieces of automation in post functions to satisfy changing requirements across multiple workflow versions, but workflow statuses are just not modular enough for that.

[Sandy Naidu]

I had the same question

[MK]

Well from what I understand, there are very little changes in the workflow that varies from one project to another. In this case you can copy the existing workflow and modify it then assign the workflow to new project(this will minimize the time taken to create workflow for new project) and of-course when you copy the workflow give it new name so that in future when you have make any changes it wont put you into a confusion.

Hope this answers serves the purpose!!!

[fran garcia gomera]

@Artemy Matvienko 

You could try to make the changes only affecting to certain projects with conditions in the transitions to those statuses. That wouldn't affect the time tracking, just prevents some projects to transition to certain statuses.

You can also create different contexts for the customfields that are only in some projects to make them only available in those projects. 

mixing both things you could have only one workflow working in different ways depending on the project you are.

[Anna Bogyo]

We are using project properties which can be defined in the description of a project see atlassian-docu like {tasktype=simple}. Such a property can be used in scripts, e.g. here as validator:

The transition requires the following criteria to be valid

1. If a value is not provided during the transition for field(s) Summary, Component/s, Description, show the following error: This field is required. 

   This validation only applies if the following condition is true:

   issue.projectObject.description.contains("tasktype=simple")

2. If a value is not provided during the transition for field(s) Summary, Component/s, Application Areas, Description, show the following error: This field is required. 

   This validation only applies if the following condition is true:

   !issue.projectObject.description.contains("tasktype=simple")

[Anna Bogyo]

Other possibility: to use project category.

[Navisha Sukurdeep]

Hi , 

I am not able to delete a project .

[Ahmet Kilic]

Hey Navisha, if you're not a system-administrator then you cannot do this. Please hit a message to your admin.

[Swami Dridapada]

Namaskaram

I find that this question will be relevant irrespective of the time of posting it!

Great Post.

My observation is that Jira is more of a plug and fit platform , with enough room for customization i.e the post functions and options for fitting in Groovy scripts and the like

So, its good that there are many work flows and it allows for the users to have as much customization as possible as long as the extent of customization is reasonable - so as to match the costs vs rewards,

To avoid the laborious task of managing work flows, certain privileges could be extended to the Project Lead and additional status / transitions could be managed by them, (They could be trained to keep track of change history separately and assist to keep is simple for everyone's sake)

Only for post functions , it is critical and very much requires our attention and access also is restricted to admins

IF users are enjoying the benefits of the additional customization, then it makes the entire exercise all the more worthwhile to do.

Please do comment your thoughts below

Pranam