nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Multiple workflows for a single issue type

HH_brlcp1

We would like to be able to apply multiple workflows to a single issue type, and pick the workflow on a per form basis.

This doesn't appear to be how it works as I did find this answer to the question: https://community.atlassian.com/t5/JIRA-questions/Multiple-workflows-for-an-issue-type/qaq-p/207307

So I was wondering what the best practice for this is?

We will potentially have hundreds of different workflows, but we don't really want to have to set up hundreds of issues types. Service Request - laptop, Service Request - new server, Service Request - password reset feels a bit messy.

Hoping you can advise on how best we could handle it!

Accepted answers

All comments

Maarten Cautreels

In the mindset of JIRA it's better to create multiple issue types and use that field to define what type of work it is and what type of workflow it requires.

The issue type is meant to indicate what type of work the issue is about. A particular type of work might require a different workflow from the other. If the workflow is slightly different depending on some properties of the type of work. You could use conditions to tweak the workflow a bit depending on those properties.

Hope this helps.

Best,

Maarten

Joe Pitt

I've used this approach and it works well if there isn't big differences in the workflow. The laptop and server request may be very similar, but I'd put the password reset as a seperate issue type.

Nic Brough -Adaptavist-

When you say "hundreds of workflows", that's probably not true. You probably have many different activities involved, but they're more about data items.

For a simple example, you might think you have different workflows for "Fix laptop" and "Fix tablet", but the processes involved in doing them are described in the same way. There's differences in the data (type of hardware to replace, or a person's expertise). Similarly, the process for an upgrade on those two is going to be the same - engineer gets hardware, does something to it, gives it back.

I would step back from your workflows and do some basic analysis on them. When they're reflecting broadly similar processes, they should be the same workflow. You can even merge similar ones by providing multiple routes through them with different conditions (e.g. for a machine fix that has a location the same as the allocated engineer, you don't bother to go through the "book site visit" part of the workflow)

HH_brlcp1

Perhaps we're planning to do this in a way that's slightly different to standard. We're going to have 15 distinct IT teams running out of one Service Desk project. Each team will get their own queue, and the front end forms will determine what happens to each request that comes in, and which teams form it ends up in.

Each team will then have a series of dashboards that they use to manage their queue on a more granular level.

However this does mean that the likelihood is we will end up having somewhere between 50-100 distinct workflows from go live of the product. Things like adding a new shared mailbox has a very distinctive workflow that may have several stages at the beginning which are similar to other requests that come in, will end up being distinct at the end. Where it will require six or seven steps that won't be the same as other requests.

For complicated workflows like this, would you still recommend going down the one workflow with multiple routes or will that get too messy?

HH_brlcp1

Hi Maarten,

Thanks for your reply, that does make sense, but I'm just a bit concerned that we're going to end up with hundreds of issue types! And that the issue types might be hard to keep tabs of. Do you know from your own experience, what the average number of issue types that a company ends up having? :-)

Thanks!

tjwood

The other problem is when you're entire company only allows half a dozen issue types for standardization across a massive company. Then multiple workflows per issue type are your only option, especially if, as is common in big companies, one department share a single Jira Project for everything, with separate boards being used for different actual projects, each of which may have different workflows. Until we have that capability, you end up with the most convoluted branching workflow if you use multiple slightly different status types to start an issue into the right branch (ex. statuses "To Do - Type 1", "To Do - Type 2", etc.) So long as people know which branching status to choose, they at least end up in the right branch of the massive branching workflow.

Nic Brough -Adaptavist-

You're right, workflow branching isn't a good idea for larger teams.

In these cases you should indeed standardise, or segment. Either stop people having variable workflows (standardise on the best ones that work for you), or let them, but break it up by giving the teams that need to work differently into different projects (and/or issue types)

Standardisation of issue types should be driven by the needs of teams configuration for them, not a simple "we only want half a dozen issue types". It is a lot better to have a long list of issue types that enable your teams to work differently, than complex and constricted workflows attached to a short list.

tjwood

Unfortunately, in massive, 100k+ people organizations, you can't do standard reporting across the board with hundreds of issue types, much less provide centralized support for that much variance. Single projects for entire departments of hundreds of people are also necessary for in-department standardization. Some times, it feels like Jira, and Atlassian projects in general, are built with so many amazing features that are, unfortunately, configured in such a way that it seems Atlassian assumes their products will only be used by smaller companies (less than 10k+ people) that exist solely in the commercial tech world. That's not the case at all.

Nic Brough -Adaptavist-

Yes, that's why you need to decide on standardise or segment. If you segment, you have to assume that you can't do simple reporting. If you standardise, you have to assume there's a lack of flexibility.

There's a reasonably simple scale here - both standardisation and segmentation can work really well, but most of us need to not be right at one end of it. And the end-user needs to know where we are.

Even Atlassian have massive problems with it - team-managed projects are really very segmented, and company-managed ones default to standardised but do have some flexibility.

It feels like there are two teams at Atlassian here - one that want to make Jira work for large organisations, and another that wants it to support teams who want to be completely independent and hence have no global reporting.

You won't have a problem finding my older postings about "team-managed projects are not ready for the enterprise yet", but they are going in the right direction - recently Atlassian added "include global fields" to TMPs, which really helps a project be shared.

TMPs especially give the impression that Atlassian stuff is aimed at smaller organisations, but I don't think it is that simple. I just don't think it's ready for the wider world.

But they have now added support for global fields which was my biggest problem with TMPs. Now if we can kill off the local fields and local status, we have a winner.

Most of my career since I stumbled into Jira has been with larger places and their problems were very much with not sharing. I ran into it when we had (very roughly) 70,000 users, then moved to a place with 150,000 potential users, then 250, then 40,000, but when Jira Service Desk arrived there, we added 60 million potential JSD-customers to it. Then I went to Adaptavist and it got a lot more complex.

You are absolutely right in your arguments about standardised reporting, it does sound like you might have some problems there

(please don't take "arguments" as me being contrary, I use the word to mean "accurate specification", not a fight. The "-l" in "ls -l" is an argument - it asks ls to do its job in a certain way)

TLDR: you have workflows that do not work because they do not map on to what your teams are doing in real life. Change that - find out how they work, build a workflow that matches what they really do. Better - build a workflow that is what you want them to do!

Ask your people why and how multiple workflows might help them. In Jira, they won't, but the question can really help.

tjwood

It's still not that simple though. It's not just software engineers using Jira anymore. Every function uses Jira: software engineers, mechanical engineers, human resources, finance, communication, security, operations, etc. To make standard reporting possible (and to make the system manageable by a small team b/c an internal team running an internal system is not a value add team to the company bottom line), data you see in a report (issue types, fields, field values, etc.) are standardized and workflows schemes are limited to a certain number of standard workflows. However, because you're dealing with so many completely different functions, employees have the ability to be creative within those limits (ex. add statuses* and transitions within the workflow schema of a project once the standard workflow is assigned), choose which fields (from the approved list of fields) to show for an issue type (or issue types if multiple issue types are assigned under a single schema), etc. If you ask, some companies will even be nice enough to give you a second workflow for a project, but it doesn't do a lot of good right now when you can't assign that second workflow to a single Issue Type.

*(Adding Statuses is also really difficult. Since we can't add statuses to a Project directly, much less to a Jira instance, several people have found a work around:

Step 1: Request that the Internal Jira Team create two projects for you.

Step 2: Use one of the projects to make as many boards as you need (since you don't have the option to Add Status to any board in a project with more than one board, which is especially problematic when most projects have 15 to 30 boards).

Step 3: NEVER EVER add another board to the second project. The whole point of the second project is just to find a way to add Statuses to the Jira instance.

Step 4: In the second project, go to the Board. Go to Configure Board. Go to Column. Click Add Status. Add the Status you need that does not currently exist in the entire Jira instance. Repeat until you have all the new Statuses you need.

Step 5: Go back to the first project. Go to Project Settings. Go to Workflows. Click the pre-set workflow you want to add a Status to. Search for the Status you just created in the second project. Add the Status. Add necessary transitions.

Step 6. Go to each board in the first project. Go to Configure Board. Go to Column. Drag and drop the new Status you just added to the correct column.)

And don't get me started on required fields lol. If the only way to make a field required is at the schema level and employees can't alter the field schemas or add new field schemas, we're completely stuck. If we could just set whether or not each field is required in each screen of each individual project, we'd be able to set required fields as needed. (And this would be especially easy when only one screen is allowed to be used for each Issue Type, or group of Issue Types depending on how it's assigned, for creation, editing, and viewing of that Issue Type.)

Large companies have standardization pretty well in hand using global settings, but there are features that exist at the global level when they should really exist at the project level. This causes features that large companies wouldn't mind their employees being able to use (like marking whether or not a field should be required on a specific screen of a specific project) to be inaccessible because they get unnecessarily caught up in global settings that have to be restricted for standardization.

tjwood

Just found another reason for multiple workflows for one issue type: so that people can't choose a status from a workflow with multiple branches when that status is not mapped to any column of the board, or any board, the issue is on.

Nic Brough -Adaptavist-

That is not a good reason for multiple workflows, it's a good reason to configure your boards correctly, and use different issue types with more simple workflows.

Nic Brough -Adaptavist-

I think I missed the longer comment before - another leader pinged me about it being marked as spam (which they undid and then told me), my last comment was about the "another reason for multiple workflows" only.

In response to the previous de-spammed one;

Jira has been used by a lot of people who simply need an issue tracker since I started using it - the first install I inherited had a load of developers, HR, and facilities management in it. (to show my age, it was a Jira 2.0 and my first big project with it was "import some stuff from another Jira 1.x", and the second, "upgrade it to 3.0)

We are talking about two big things here - workflow and fields (there are, of course other things to talk about, but I think they can mostly be considered in similar way to those two)

Here, it's quite clear:

Use a single project
Use a suitable workflow

and then

Make the admins configure the right fields, both available and mandatory/optional
Make the admins configure the workflows that suit best

bearing in mind

question every new status, share them between workflows. A workflow should represent a way of working, but be reportable
question every new field, share them as much as possible. You really don't want 40 pairs of "start date" and "end date", you want one. (That's a real-life example, albeit 12 years old)

TLDR: you really really need to talk to your admins

tjwood

This is where I think Atlassian underestimates how big companies that use their software work. Employees in a company of over 100,000 people don’t get a say in how the single company-wide Jira instance is run. Internal tools like this are a cost to companies, not a value add. As such, they are maintained by small teams with limited resources and budget. All employees can do is work within the confines of a company-wide Jira instance. This is common for many company-wide tools. However, while other tools relegate certain basic features to the lowest level so that employees can make the most of a product even under these circumstances, Atlassian has a habit of bundling simple features at higher levels into groups of features that are essentially turned on or off as a whole. If something can be turned off at the admin level to make management of the system easier or less costly in a huge company, it usually will be turned off, no matter what the ripple effects are. (Ex. I’m trying to make the case for issue-level security to be turned on when requested. I have to prove it won’t be an undue burden.)

tjwood

A second example of this sort is the fact that notification settings are at the project level. When all work done in an entire department is required to be in a single Jira project, the notification settings are whatever the highest ranking person (Director, VP) in that department wants them to be. The hundreds of other people just have to deal with it because we can’t change are own settings.

Nic Brough -Adaptavist-

>This is where I think Atlassian underestimates how big companies that use their software work.

It's the opposite - they've moved into competing directly with other issue trackers that think they know how big companies work, and their successes in that area is a testament to them actually doing it right. Legacy systems like Remedy and Cherwell are being wiped out by better systems, like Jira.

>Employees in a company of over 100,000 people don’t get a say in how the single company-wide Jira instance is run.

Yes, that's where you have company-managed projects. You need that to ensure consistency of reporting (and process, and and and, but I don't believe you need a lot beyond consistency of reporting)

This is also why I'll say that team-managed projects are not ready for large organisations. They don't give us that consistency of reporting yet.

And, most importantly in this conversation, you simply can't be consistent if you try to botch in "many workflows for an issue type". You have to have something that defines the process an issue will follow, and the best thing to do is use the issue type, because it's unequivocal and clear to the users.

>Internal tools like this are a cost to companies, not a value add.

So companies don't need issue trackers? Are you sure about that?

>Ex. I’m trying to make the case for issue-level security to be turned on when requested. I have to prove it won’t be an undue burden.

You might have a problem there. It's not as easy to explain as I'd like it to be, but it does match some use-cases very very well. I try to keep it a) as simple as possible and b) limited to the teams that really really do need it (frankly, the only teams I will not say "no" to as a first response are the HR and Security teams)

>A second example of this sort is the fact that notification settings are at the project level.

Why is that a problem? Notifications have little to do with workflows and having multiple workflows would have no effect on notifications.

tjwood

To be clear: I love Jira and am thrilled it’s becoming more and more popular.

In large companies though, the idea that they’ll allow company managed vs team managed products is an assumption that isn’t borne out. Leadership wants standard reporting on EVERYTHING. But I’ve yet to meet anyone who cares about standardizing workflows for reporting. That’s for efficiency and to keep costs (the managing team and resources) down because those are controlled at the instance level, not the project level, and would be too much for the small Jira team to keep up with in a large company. No matter how much Jira, or any internal tool, does add value to a company (and I personally think it’s a huge benefit) accounting never sees it fully as value add when you could do the same (however painfully) with Word, Excel, or PPT.

As for notifications, I just meant that was another (but separate) example of where not putting features at the individual user level causes frustration. I get 50-60 Jira emails per day minimum (not exaggerating) because the leadership of so of the Jira Projects I’m on want notifications for everything, and there’s nothing I can do about it under the current Jira notification set up.

Nic Brough -Adaptavist-

Yes, that's standardisation making your life hard. The only way to "fix" it is to work with your admins and leaders to improve the standard processes (and hence Jira config).

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

jira-service-desk

workflow

issue-type