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:
You will see the work category-specific queue appear in your project.
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
