It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

How to manage many similar workflows? Edited

Artemy Matvienko Oct 09, 2018

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?

3 comments

Pete Singleton Oct 09, 2018

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 Oct 09, 2018

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.

Like Myles Fullen likes this
Artemy Matvienko Oct 09, 2018 • edited

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 Oct 10, 2018

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 Oct 10, 2018

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'm New Here Feb 14, 2019

I had the same question

Muthanna May 15, 2019

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!!!

Comment

Log in or Sign up to comment

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you