JinJin48

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

July 18, 2026 · 13 min read

SAP Service Cloud Service Catalog

Service Catalog is SAP Service Cloud’s parent/container master for Service Category: “Service catalogs are collections of service categories. Each service category must be assigned to a service catalog.” A catalog is a named, statused record scoped to one or more transactional object types — Case, Phone, Chat, Email — and it is the one master in this Phase 4 cluster with a genuine, explicitly documented structural link to another master data object: a Case Type may optionally reference a Service Catalog, but only while that case type is in draft status. This article maps that containment and assignment structure, the four-level category hierarchy a catalog carries, its field-level content, and the objects it deliberately does not connect to.

Part 1: Service Catalog — Core Concepts (All Modules)#

1.1 What Is the Service Catalog?#

Service Catalog exists so that a company’s services can be classified consistently across every interaction channel a customer might use — a case, a phone call, a chat — rather than each channel inventing its own free-text labels. It is not the classification itself: the individual service labels live one level down, on Service Category (SC-A05-02). The catalog is the named, statused container that groups those categories together and declares which object types the whole grouping applies to.

1.2 Object Types Supported#

A catalog is not automatically available everywhere it might be used — each catalog declares, via a single multi-value field, which transactional object types its categories can be selected on. Getting this scoping wrong means a catalog cannot be assigned to Case Types or selected in the interaction dialogues for the object types it is missing. This is stated explicitly for the Case Type link: the Set Up Guide’s Ch. 10.6 Note on selecting a catalog for a Case Type reads, “You can only select catalogs set up for use with cases” — i.e., a catalog’s Object Types Supported value must include Case (2886) before it is even eligible to be assigned to a Case Type, regardless of its Catalog Status.

Design principle: “If the catalog is used for all object types, enter ‘2886’;‘86’;‘1976’;‘39’ in the field.” Object Types Supported is a combinable, multi-value field, not a single choice — a catalog can be scoped narrowly to one channel or broadly to all four.

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)
   │
   ├── Service Catalog "SVC-CATALOG-AUTO" — Object Types Supported: Case, Phone, Chat, Email; Catalog Status: Active
   │       │
   │       └── Service Category (Level 1) "Vehicle Service" — Catalog Display ID: SVC-CATALOG-AUTO
   │               │
   │               └── Service Category (Level 2) "Engine" — Parent Category Display ID: VEHICLE-SERVICE
   │                       │
   │                       └── Service Category (Level 3) "Oil Change" — Parent Category Display ID: ENGINE
   │                               │
   │                               └── Service Category (Level 4) "Synthetic Oil Change" — Parent Category Display ID: OIL-CHANGE (maximum depth)
   │
   └── Case Type "Vehicle Repair Case" ── assigned to (draft status only) ──> Service Catalog "SVC-CATALOG-AUTO"

Design principle: Service Category nests inside Service Catalog up to four levels deep — corroborated independently by both the Case entity’s Category Level 1–4 fields and the AI Configuration chapter’s “use up to four levels of categories” instruction. Case Type’s link to the catalog is a one-time assignment, not containment — the arrow above, not a nested box — because a case type does not own or contain the catalog; it merely references it, and only while still in draft status.

1.4 Integration with Other Master Data Objects#

Service Catalog is the rare object in this batch with two genuine, sourced structural relationships rather than one — a mandatory containment relationship to its own child (Service Category) and an explicit, one-time assignment relationship to a master object outside its own hierarchy (Case Type). It is worth being just as explicit about what it does not connect to, since several of the objects below share a Phase, a chapter, or a business-service naming pattern with Service Catalog and could otherwise be assumed related.

Case Categorization (AI/ML) as a downstream consumer: Beyond Case Type and Case, the catalog structure feeds a third consumer that is not a data-import relationship but a practical one worth flagging on its own. The Case Categorization machine learning model learns from “your past cases and category catalog” to auto-propose a category on new cases once trained and activated. This carries a documented caveat any team planning to restructure a live catalog should know in advance: per the Set Up Guide’s model-configuration procedure, “If you update your service category catalog, you must map new category IDs to existing categories and retrain your model.” In other words, once Case Categorization is live, a catalog or category hierarchy change is not a free edit — it requires an explicit re-mapping and retraining step before the model’s proposals stay accurate.

Scope notes: (1) Naming collision — Service Cloud’s “Service Catalog” is unrelated to the S/4HANA/Fiori “business catalog” authorization concept that also appears in SAP’s documentation; the two share a name only, and this article’s Service Catalog is never used for authorization. (2) Whether a tenant can maintain multiple simultaneously-active catalogs of the same object-type scope, and if so how one is chosen at Case Type assignment time, is not documented in any SAP-official source found — the Feature Scope Description confirms a tenant can “configure one or more service catalogs,” but no source describes a precedence rule among them. Treat multi-catalog-per-object-type behavior as an open item, not a confirmed mechanism.

Part 2: SC-Specific Field Details#

2.0 Scope of SC Ownership#

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

2.1 Catalog Header (Base Attributes)#

This is the single root record behind every Service Catalog — get these fields right and the catalog exists, is correctly statused, and is scoped to the right channels.

2.2 Catalog Names / Catalog Descriptions (Translation Sub-files)#

The root Catalog Header record only stores Name and Description in English. Additional languages are added through two parallel sub-files that share the same three-field structure.

Prerequisite: This pattern is identical to Service Category’s own Category Names / Category Descriptions sub-files one level down (SC-A05-02) — the same parent_external_key / content / languageCode structure repeats at both the catalog and category level.

What to Read Next#

L1) Big Picture

L2-A) Master Data

L2-B) Transaction