JinJin48

SAP Consultant | BTP · S/4HANA · US Global Rollout

July 18, 2026 · 18 min read

SAP Service Cloud Case Type

A Case Type is not a simple category or classification value that an admin picks from a list — it is a copyable process template that carries its own phases, steps, approvals, automated flows, schemas, and feature toggles, and that a Case is instantiated against at creation time. There is no “create new” action for a Case Type; every new one starts life as a copy of an existing Case Type (SAP ships a starter template, “SMPL - Sample Case Type,” for this purpose), and it lives in Draft status until an administrator finishes configuring it and switches it to Active. This article covers what a Case Type record actually owns, why most of its settings can only be edited while in Draft, resolves the common assumption that it links directly to Service Category, and establishes the direction in which downstream objects like Case Routing Rules and Service Level Determination consume it.

Part 1: Case Type — Core Concepts (All Modules)#

1.1) What Is the Case Type?#

A Case Type exists to model one distinct service process — a product complaint, a warranty claim, a general service request — as a reusable template rather than a one-off configuration on every case. It is the object an administrator decides how many of are needed for the organization: “it is the administrator’s responsibility to determine if one or multiple Case Types are necessary.” Once instantiated, a Case is a live record of a request that runs through the phases, steps, approvals, and automated flows defined on its Case Type, visually guiding the agent through processing it.

Design principle — Case Type is a template, not a category. New Case Type codes must be created in the customer (Z) namespace — up to four characters, no spaces or special characters — and are always produced by copying an existing Case Type via “Copy to New Case Type,” never by a blank “create” form. After copying, the administrator sets a Case Type ID and Description and the record starts in Draft status. This copy-first, template-based creation pattern is itself evidence that a Case Type is a structural process definition (flow + schemas + feature toggles), not a lightweight lookup value like Service Category.

Common misconception — Case Type does NOT reference Service Category directly. A Case Type optionally selects a Service Catalog — nothing more. It has no field, setting, or dependency entry pointing at any Service Category or category level. The categories an agent then sees when creating a Case of that type are simply whichever categories happen to belong to the assigned catalog; SAP’s own guidance for making category fields editable on a case is explicitly to “ensure that the Case Type used has a catalog assigned,” never to assign a category to the Case Type itself. If the Case Type carries no catalog, the category fields on a new Case stay non-editable, regardless of how many categories exist elsewhere in the tenant. See Section 1.4 for the full relationship table, and SC-A05-02 (Service Category) for the same conclusion reached independently from the category side.

1.2) Case Type Lifecycle: Draft, Active & Create New Version#

Getting a Case Type’s status wrong is not a cosmetic mistake — it directly determines whether the fields that define its process are editable at all, and SAP documents this as intended behavior rather than a limitation to work around.

Design principle — existing Cases are version-pinned, not live-linked. “Once a case gets created on a specific case type, it will be bound to that type but also to the current active version of that type” — this is documented explicitly as system-designed behavior, not a defect. Practically: if you create New Version 2 of a Case Type and change its assigned Service Catalog, every Case created under Version 1 keeps Version 1’s catalog (and therefore its original category tree) — the change does not retroactively apply. Plan Case Type version changes with this in mind; reassigning a catalog on a new version does not migrate the categorization of cases already in flight.

1.3) Organizational Levels and Data Hierarchy#

Data hierarchy with a concrete example (tenant-level; SAP Service Cloud has no Company Code / Plant scoping above this)

Client (SAP Service Cloud Tenant)
   │
   ├── Case Type "ZVRC - Vehicle Repair Case" (copied from "SMPL - Sample Case Type"; Status: Active, Version 2)
   │        │
   │        └── assigned to (Draft status only) ──> Service Catalog "SVC-CATALOG-AUTO"
   │                                                    (never assigned directly to any Service Category level)
   │
   └── Service Catalog "SVC-CATALOG-AUTO" — Catalog Display ID: SVC-CATALOG-AUTO; Object Types Supported: Case, Phone, Chat, Email
            │
            └── Service Category (Level 1) "Vehicle Service" — Category Display ID: VEHICLE-SERVICE
                    │
                    └── Service Category (Level 2) "Engine" — Category Display ID: ENGINE
                            │
                            └── Service Category (Level 3) "Oil Change" — Category Display ID: OIL-CHANGE
                                    │
                                    └── Service Category (Level 4) "Synthetic Oil Change" — Category Display ID: SYNTHETIC-OIL-CHANGE

   Email Channel "Support Inbox" ── determines (via Case Type Determination Rules) ──> Case Type "ZVRC - Vehicle Repair Case"

   Case Routing Rule "Route Vehicle Repair to Field Team" ── matches on (mandatory) ──> Case Type "ZVRC - Vehicle Repair Case"

   Service Level Determination Rule "Auto SLA - Urgent Repair" ── matches on (input) ──> Case Type "ZVRC - Vehicle Repair Case"

Design principle: Case Type sits beside Service Catalog at the tenant level, not above or below the category tree — its only outbound arrow into the catalog/category structure stops at Service Catalog. Everything below Service Catalog (the four Service Category levels) is reached only transitively, through whichever catalog the Case Type happens to reference, and only while that reference exists. In the opposite direction, Case Type is itself the target of two separate arrows shown above: an Email Channel’s Case Type Determination Rules can select it automatically at case-creation time (an upstream determination step, distinct from the downstream consumers), while Case Routing Rule and Service Level Determination Rule both treat an already-assigned Case Type as one of their own match conditions. Case Type never reaches back into either of those two objects — the dependency runs one way, into Case Type as an input.

1.4) Integration with Other Master Data Objects#

A Case Type touches several other master data and configuration objects, but in two clearly different directions: it is optionally the source of one link (into Service Catalog), and it is the target that several downstream objects reference as an input. The table below is explicit about which direction each relationship runs, and flags the items the source material could not fully confirm.

Scope notes: (1) No source directly states that a Case Type ID is immutable once created — indirect evidence (the Z-namespace prefix rule, and the fact that every field change routes through “Create New Version” rather than an ID-edit action) supports treating it as a permanent key in practice, but this article does not assert a documented immutability rule. (2) Whether a “Default Team/Queue” field exists natively on the Case Type record could not be confirmed either way from the sources used; routing to a team or employee appears to be governed entirely by separate Case Routing Rules that consume Case Type as an input, rather than a field stored on Case Type itself — treat this as the working assumption, not a confirmed absence.

Part 2: SC-Specific Field Details#

2.0) Scope of SC Ownership#

Legend: ◎ = Owner / Critical, ○ = Direct involvement

2.1) Case Type Header (Base Attributes)#

This is the identity record every Case Type has, regardless of what its flow or settings look like — get these fields right and the Case Type is correctly named, correctly statused, and traceable back to whichever template it was copied from.

2.2) General Settings#

General Settings are the structural configuration that gives a Case Type its numbering, status flow, and party model — plus the optional catalog link discussed throughout Part 1. All four fields share the same Draft-only mutability rule from Section 1.2.

2.3) Feature Settings#

Feature Settings are togglable capabilities layered on top of the core case flow — each one turns on a distinct agent-facing or automation capability for Cases of this Case Type, independent of the General Settings above.

2.4) Case Flow (Phases, Steps, Approvals, Automated Flows)#

Case Flow is the actual process definition behind a Case Type — the reason it is described as a template rather than a classification value. It is composed of phases, steps, approvals, and automated flows that visually guide an agent through processing a Case, and, like the General Settings above, it can only be edited while the Case Type is in Draft status.

Prerequisite: Because Case Flow is editable only in Draft, any change to phases, steps, approvals, or automated flows on an Active Case Type requires Create New Version first (Section 1.2) — there is no in-place edit path for a live Case Type’s flow.

What to Read Next#

L1) Big Picture

L2-A) Master Data

L2-B) Transaction