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; } } }

🎁 JSM Advent Calendar - Day 2: Request Types (Sorting the Letters)

Kate Pawlak _Appsvio_

Jira Service Management - Advent Calendar_day2.png

✉️ Sorting Letters to Santa

Yesterday, we built the Front Door (The Portal). Today, we need to make sure the mail goes to the right desk.

The Scenario:

Santa gets millions of letters. Some are simple ("I want a bike"), and some are complex ("I want world peace"). If the elves threw them all into one big sack labeled "General Stuff," the logistics team would collapse.

The Reality:

In many HR teams, everything comes in as a generic "Get Help" ticket. Treating an "Address Change" the same way as a "Harassment Complaint" is a recipe for disaster. They require different information, different urgency levels, and different privacy settings.

The JSM Solution:

Request Types. Don't just use a generic form. Create specific Request Types for specific needs.

Onboarding: Triggers a workflow involving IT and Facilities.
Payroll Dispute: Routed directly to Finance with high sensitivity.
Leave Request: Requires manager approval steps.

🎁 Tip of the Day:

Map your Request Types to specific Issue Types in the background. This allows you to show different fields for different problems.

Maternity Leave asks for: "Due Date."
Address Change asks for: "New Zip Code."

Keep the forms relevant so you don't have to email back and forth asking for missing details.

❄️ Let’s chat: Do you have a "Miscellaneous" or "Other" category in your service desk? Be honest - is it currently a black hole where tickets go to die?

Comments

Mick Szucs

Map your Request Types to specific Issue Types in the background. This allows you to show different fields for different problems.

Is this actually good advice?

I thought best practice was to use customized screens for multiple request types on a minimized number of Issue Types?

This approach would lead to a 1:1 relationship between the numerous types of "Service Request" and "Work Item Types," which seems like a lot of work to maintain over time, but certainly offers some advantages with regard to screen configuration, etc.

How do folks typically manage this?

Thanks!

Kate Pawlak _Appsvio_

Thanks so much for this great question, @Mick Szucs - and for calling this out. I may indeed have used a bit of a mental shortcut in the article, so I’m happy to expand on that here.

First of all, in company-managed projects, mapping Request Types to Issue Types is actually mandatory. In team-managed projects, on the other hand, you work only with Request Types, for which you directly define fields and workflows - without the classic Issue Type configuration layer.

Now, I fully agree with you that a strict 1:1 relationship between every Request Type and its own dedicated Issue Type would quickly lead to chaos and would be completely inefficient to maintain long-term. That is definitely not what I meant as a general recommendation.

Using the examples I mentioned - Maternity Leave and Address Change - I only highlighted the difference in fields at the Request Type (form) level. And of course, in such a case, both of these can absolutely be mapped to the same Issue Type, with the differences reflected purely in separate Request Forms.

However, when we go one level deeper into these examples, the difference is very likely also in the workflow:

Maternity Leave often requires one or more approvals and may trigger follow-up tasks (for example, defining a substitute, handover of responsibilities, etc. - which can be handled via automation).
Address Change is usually a simple operational update without any complex workflow logic.

And this is where the Issue Type becomes the key design element, because workflows are defined for Issue Types, not for Request Types.

If both Request Types truly shared the same workflow, then of course it would make no sense to create two Issue Types like “Maternity Leave” and “Address Change”. A single, generic Issue Type such as “Employee Request” would be the right choice.

For completeness, here’s also the relevant Atlassian documentation that explains this distinction very clearly:
https://support.atlassian.com/jira-service-management-cloud/docs/whats-the-difference-between-request-types-and-issue-types/

Thanks again for raising this - it’s a really important nuance.

Welcome!

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

Quick Links

Find more posts tagged with

cloud

jira-service-desk

jira-service-desk-cloud

customer-portal

request-type

jira-service-management-cloud

jira-service-management

jsm

help-center