Issue type (work type) vs request type in Jira Service Management: Do I need both?
Issue type vs. Request type
Ever thought why should we even bother with request types in JSM? What is even the difference between issue type and request type in Jira? Request types feel like extra bureaucracy. We already have work types (issue types), and they are totally enough!
No, they are not!
Issue types are what your service team works on inside Jira; request types are the friendly forms customers fill out to create those issues.
How it works
|
Request type (customer‑facing form) |
Underlying issue type (agent‑facing) |
|---|---|
|
“I forgot my password” |
Service Request |
|
“New laptop request” |
Service Request |
|
“Access to SaaS tool” |
Service Request |
|
“Something’s broken” |
Incident |
|
“Website is down” |
Incident |
All of the “New laptop”, “Password reset”, and “Access to SaaS tool” forms above create the same Service Request issue type in the queue, but each form:
-
shows only the fields you choose for that scenario (e.g., laptop model vs. system username),
-
has its own friendly name, icon, and help text on the portal,
-
can live in a different portal group (“Hardware”, “Accounts”, etc.),
-
can have its own automation triggers (because you can filter on Request type = “New laptop request”).
That is how we keep it at Actonic:
Why use multiple request types for one issue type?
It give you absolute control over two viewpoints:
|
Who’s looking? |
What they see |
Why it matters |
|---|---|---|
|
Agents / IT staff (inside Jira) |
Issue type, e.g. Service Request, Incident, Change |
Drives the workflow, SLAs, fields, and reports. |
|
Customers / Employees (help center) |
Request type, e.g. “Reset my password”, “Order a laptop” |
Makes it crystal‑clear how to ask for help and what info to provide. |
How they connect
-
One issue type can have many request types.
Example: The single issue type Service Request might power the request types “Need a new monitor”, “VPN access”, and “General question”. -
A request type must map to one issue type, but never the other way around.
-
Change the issue type’s workflow or fields → every request type that points to it inherits those changes.
Why bother with both?
|
Benefit |
What it does for you |
|---|---|
|
Cleaner customer portal |
Users see plain language (“My screen is cracked”) instead of IT jargon (“Incident‑Low Severity”). |
|
Less configuration overhead |
Keep a small, tidy set of issue types; just add more request types as new scenarios pop up. |
|
Targeted automation & SLAs |
Automations can trigger on request type = “Order laptop” even though it’s still a Service Request under the hood. |
How do I create a request type in Jira Service Management?
Just follow these 3 steps:
-
Add request type
Project Settings → Request types →Create request type. You can create from blank, use a template or AI help! -
Design the portal form
Drag the fields you actually need, rename them in human words, hide geeky ones. -
Save & test
Open the Help Center as a user and make sure it looks and feels right.
It is that easy! Give it a try yourself!
Cheat sheet
|
If you hear… |
Think… |
|---|---|
|
“Issue type” |
Engine! That’s how Jira processes the ticket. |
|
“Request type” |
Front door! That’s how users ask for help. |
|
“Many request types to one issue type” |
Lots of doors, same room behind them. |
|
“Why does my new field not show on the form?” |
It isn’t on the issue type’s screen yet. |
Bottom line
Issue types keep your internal process stable.
Request types keep your customers happy.
Treat issue types as the skeleton and request types as the costume. Together they let you run a tidy service desk and give users a no‑brainer way to ask for what they need.