Request type, work type, work category, category group... what else....

[Wolf Duttlinger]

Hi,

maybe someone can shed some light on this - preferably not in a sequence of partially outdated pages.... ;-)

I'm using the free tier of JSM to explore the possibilities.

I see that there are work types - I basically understand this as the "different tables" for for different ticket types.
Then I see request types - in my mind these are different forms to enter tickets into one of these "tables".
Now I see that there are "work categories" - https://support.atlassian.com/jira-service-management-cloud/docs/how-categories-work-in-it-service-management-projects/ - that seem to be somehow linked to the "default" JSM work types.

I also see request category groups - but these seem to be only there to be able to group different request types for selection and presentation.

Does anybody have something like an ER daigramm or similar for all the groups, schemas, types and categories around?

Thanks

Wolf

[Wolf Duttlinger]

Thanks for the quick and good answers.
@Lara Demir - Hipporello  - you mention "issue type" - I guess this is the "old term" for "work type"?

I guess I understand the request type - issue type connection. What I'm lacking is to understand what's the "value add" of work category. If work type defines the fields in use and workflow connected - what is left? (BTW - when I customize the queue columns I can't display the work type - there is only an "issue type"...)

And: shouldn't I first start with the WORK types and then - e.g. if needed to collect different information for different work groups/topics etc but where the resolution generally adheres to the same "workflow" and where this difference in information can't be handled by "dynamic forms" - then split this up into different request types?

[Arkadiusz Wroblewski]

Hello and Welcome @Wolf Duttlinger 

I will keep this on Simple explanation Layer.

in JSM, I would read it like this:

Work type = the underlying Jira object, workflow, fields, permissions

Request type = the customer-facing form/entry point in the portal

Work category = the ITSM classification, for example Incident, Service request, Problem, or Change

Portal group = just how request types are grouped visually in the portal

So for JSM specifically:

customer selects Request type → JSM creates the underlying Work type → Work category tells Jira what kind of service-management process it belongs to. Atlassian’s docs describe request types as the portal-facing layer on top of issue/work types, and work categories as the ITSM buckets used in service projects.

Shorter said:

Request type = what the customer sees
Work type = what Jira uses underneath
Work category = what kind of JSM process it is.

[Lara Demir - Hipporello]

Wolf, I hear you. Navigating the "layered" terminology in JSM can feel like an archeological dig through different eras of Atlassian product design.

To give you the clarity you're looking for, here is a breakdown of the hierarchy and the "ER logic" connecting them, written in the standard Atlassian Community style.

The JSM Taxonomy: A Functional Hierarchy
Think of the relationship like a Russian Nesting Doll, moving from the technical core (Jira) to the user experience (Portal).

1. The Database Layer: Issue Type

What it is: The underlying technical schema. It defines which fields exist and which workflow (status steps) the ticket follows.

Analogy: The "Table" in a database.

2. The Professional Layer: Work Category

What it is: Pre-defined ITSM buckets (Service Request, Incident, Problem, Change).

Why it matters: JSM uses these to unlock specific features. For example, the "Change Calendar" only looks at tickets mapped to the Change work category.

Relationship: One Work Category can contain multiple Issue Types.

3. The Customer Layer: Request Type

What it is: The "Form" the customer sees on the portal.

Analogy: The "Menu Item." You might have three different Request Types (e.g., "Request Laptop," "Request Software") that all feed into a single Issue Type (Service Request).

Relationship: Maps N:1 to an Issue Type.

4. The Visual Layer: Portal Groups & Request Categories

Portal Groups: Purely for UI organization on your specific help center (e.g., "Hardware," "Access").

Request Category Groups: A newer, high-level reporting layer that can span across multiple projects/teams to group similar work for global analytics.

The "ER Diagram" Mental Model
If you were to map the cardinality, it looks like this:

Work Category (ITSM Bucket) ➔ Issue Type (Schema) ➔ Request Type (Portal Form)

"What else?" — The missing pieces
Since you are exploring the Free tier, here are the next three terms that will likely trip you up:

Services: High-level business offerings (e.g., "G-Suite," "Office VPN"). You can link these to tickets to see which service is failing most often.

Organizations: Groups of customers (e.g., "Client A," "Finance Dept"). This allows users to share tickets with their colleagues.

Assets (formerly Insight): The CMDB. It’s where you store "Objects" (Servers, Laptops, Licenses) and link them to the ticket so the agent knows exactly which physical device is broken.

Pro-Tip: If you're building your first project, always start by defining your Request Types. Jira will usually handle the mapping to Issue Types and Work Categories automatically in the background.

Would you like me to clarify how to map a custom Issue Type to a specific Work Category to ensure your queues work correctly?