Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Celebration

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root

Avatar

1 badge earned

Collect

Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!

Challenges
Coins

Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.

Recognition
Ribbon

Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!

Leaderboard

Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
4,415,125
Community Members
 
Community Events
170
Community Groups

How to manage many similar workflows?

Edited

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?

7 comments

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.

Like Scott Patten likes this

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 # people like this

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.

Like Nina Clements likes this

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.

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.

Like Nina Clements likes this

I had the same question

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

@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.

Like Rikard_Berg likes this

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")

Other possibility: to use project category.

Hi , 

I am not able to delete a project .

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

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

Comment

Log in or Sign up to comment
TAGS

Atlassian Community Events