Work categories are available in Jira Service Management!

[#1]

We are very excited to announce that work categories can now be used across all of your service desks (these were previously pre-built into the ITSM template). Additionally, we’ve shipped feature improvements that provide admins with the control and flexibility to continuously tune and streamline the agent experience.

We’ll dive into all of this later on, but first…

What are work categories?

Work categories are groups of request types that share a similar use case (e.g., service requests, incidents, changes, problems, post-incident review) and may have additional functionality to help satisfy that use case (for example, the “Incidents” work category comes with incident management features like alerts and the changes work category comes with change management features like the change calendar).

And keep an eye on this space, that list of features will only grow over time!

While these features are not necessarily mapped to an issue type, we provide issue types out of the box that provide the recommended fields and workflows for you to get the most out of the work category. Let’s take an example. If you are using the “General service desk” template and turn on “Incidents”, you have the option of selecting the “[System] Incident” issue type (we will create and modify all the required configuration objects under the hood for you) or simply using your existing issue types (although you may need to modify them for certain work category-specific features to work. Learn more about this here).

How does it work?

To turn a work category on or off, navigate to the “Features” page (“Project settings” > “Features”). You can click on any of the work categories and turn them on or off as you wish. If you turn off a work category that has request types associated with it, we will move those request types to “Unassigned” (after confirming with you, of course!).

Work categories used to live in the “Feature lab” while they were in beta testing . So, what’s changed? Work categories are now fully flexible and modular, meaning that you can move request types across work categories as you require and can turn work categories on or off as needed. This means that you can configure them as you need and continually refine them over time.

Once you turn on a work category, you will notice two changes:

1. You will see the work category-specific queue appear in your project.

2. You will see the work category appear on the request types page as a group of request types. Any non-categorized request types will be left as “Unassigned.”

You can then allocate your request types as you prefer. There are two ways to do this.

• Assign: This is best for bulk moving multiple request types into a single work category. You do this by navigating into the work category (from “Project settings” > “Request types”) and clicking on “Assign”.

• Move: This is best for when you mistakenly move a request type to a certain work category and need to move it. These are available in the ellipsis menu within the “Request types” page.

How should you use work categories?

Work categories add powerful capabilities to your service desk (such as the change calendar, CI/CD integration, alerts, on-call, major incident escalation). It’s really up to you to decide which of these meet your needs. We recommend first testing them on a test service desk project so you understand what they offer. We highly recommend them for IT or DevOps teams but also recommend them for other teams, like customer / client support, HR and any team that might need them.

If you adopt work categories, we recommend that you allocate most (if not all) of your request types to one of the five groups (described below). Most of your request types will tend to be service requests. If you have specific request types for tasks or other work that sits outside these categories, you may want to keep them as “Unassigned”.

Let’s walk through our five work categories:

• Service requests: These are general request types for request basic support, new hardware, VPN access etc. Most of your request types will belong here.

• Incidents: This is where an application or hardware system stops working and needs immediate attention. Additional features include alerts, on-call schedule, service registry integration and major incident escalation to ensure that when something goes wrong, the right people are contacted as soon as possible.

• Changes: This is for any change that is requested and scheduled. For example, a developer may want to push changes to an application or an IT team member may need to replace a server. We provide workflows out of the box that facilitate high velocity ITSM by minimising approval time. We also provide features like the change calendar to promote visibility of planned changes.

• Problems: This is for activities that aim to understand the root cause of incidents and take preventative measures accordingly.

• Post-incident reviews: This is for immediate action following an incident to make sure that proper documentation is written up to facilitate better problem management down the line.

What do you think?

Now it’s your turn to have a look and tell us what you think. Open up a test project and have a look. We’d love to get your thoughts on the experience!

Jehan Gonsalkorale

Product Manager, JIra Service Management

[Dave Mathijs]

What happens if [System] is removed from the name of the issue type? I don't understand why this prefix is necessary.

[Jehan Gonsalkorale]

Hi @Dave Mathijs , that's a very good question. Nothing actually happens and issue types are something that experienced admins should rename based on their needs. The only thing that will happen is that we will still offer the option of creating our out of the box issue type again (in the drop down when you create a new request type and select the issue type). 

This is simply something you can ignore. Other than that, absolutely nothing will happen. 

Hope that helps, 

Jehan

[Rune Rasmussen]

Are there any plans to let admins create custom work categories?
Being able to define the criteria for our own work categories would be good.

I like the idea of work categories, but given that they are predefined, and basically glorified queues, their use seem quite limited and it feels like they go against the grain of the high level of customizability offered by Jira.

//Rune

[Jehan Gonsalkorale]

Thanks for your comment @Rune Rasmussen, I understand where you are coming from. This is something that we may explore in the future. Work categories do provide more functionality than simply queues as some have additional features (for example, "incidents" has incident management features like major incident escalation etc.). That said, custom work categories do make a lot of sense and may be something we investigate in future. 

Hope that provides some clarity as to where we are headed, so we can't accommodate this in the short-term. 

Best regards,

Jehan

[Paweł Światły]

Hello,

honestly I don't truly see the difference between Issue Type and Work Category. I am using Issue Types to differ Service Requests, Incidents etc. Why and how can I start using Work Categories?

Best regards

Paweł

[Jehan Gonsalkorale]

Hi @Paweł Światły, you ask a very good question. 

Work categories are groups of request types that share a similar use case and may have additional features. This essentially gives you category-specific queues and features like major incidents, the change calendar, alerts etc. 

In JSM, issue types provide configuration that can be used when configuring request types. For example, issue types map to a workflow and a screen scheme (typically per project given the existence of schemes and the convention of having unique schemes per project). 

Our ITSM template has a 1:1 mapping of issue types and work categories (at least, for the most part). So, they do appear largely the same as no issue type ever straddles multiple work categories (although this is by convention and not something we enforce). So, you do not have to keep this mapping. 

Which brings me to your question, why and how should you start using work categories? I'd recommend using them if there are specific features you need. For example, if you need incident management or change management features, turning these on and mapping them to existing request types that are used for those purposes could unlock value for end users. For example, you could turn on incident management and allocate "Report an incident" to the "Incidents" work category. This would enable you to set up alerts and responders to major incidents etc.

While you could also use these to simply group request types, if you are already achieving this with issue types, then there may be no benefit in doing this. But other users that have a different issue type configuration (such as having one issue type for multiple ITSM practices or multiple issue types for single ITSM practices) might find that work categories provide an easier means of grouping request types, both for a better agent experience and for reporting purposes. 

I hope this helps, really appreciate you taking the time to ask the question (and you are not the only one who has asked this, so this will hopefully benefit other JSM users!). 

Best regards,

Jehan

[Rune Rasmussen]

Do we have a exhaustive list of which features are enabled on whatever set of fields they require?
I feel like I have gone through the documentation a couple of times, but only find wordy listings of examples.
A table of which features goes where would be very convenient.

Also, for the sake of customizability, has it been considered, or could it be considered, to allow these added features to be untied from their requirements?
Then we could have the Change Calendar (or whatever) be available without adding a bunch of fields we may not require.

[Jehan Gonsalkorale]

Thanks Rune, these are very good questions. As many things have been enabled recently, I'll ask the team so I can get the most up to date information. 

[Jehan Gonsalkorale]

Hi @Rune Rasmussen, the best documentation that is currently available is located here.

I can understand if this doesn't meet your needs and will flag that a more exhaustive list or table would be more useful. 

As for customisability, features that should be available for all request types will likely more broadly available in the future, so I'll pass that feedback onto the relevant teams. 

I hope that helps, 

Jehan

[Rune Rasmussen]

Thank you @Jehan Gonsalkorale

I'll check in at a later time to see if the documentation has been updated.

//Rune

[Christian Happel]

@Jehan Gonsalkorale I think there's a small error in the link to the documentation you provided above. I assume it should be this one: What are work categories? | Jira Service Management Cloud | Atlassian Support