JinJin48

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

July 19, 2026 · 16 min read

SAP Service Cloud Service Level

A Service Level is not the rule that decides which SLA a Case gets — it is the SLA target itself: a set of Milestone due-dates (Response, Initial Review, Completion, Resolution) measured against an embedded Operating Hours definition, and nothing more. There is no Priority field on the record, and no reference back to Case Type or to any determination rule. This article covers what a Service Level record actually owns, how hour-based and day-based Durations behave differently against Operating Hours, resolves the common assumption that a single Service Level can vary its targets by priority internally, and establishes the one-directional relationship in which Service Level Determination (SC-A06-02) consumes Service Level — never the reverse. It also flags a naming collision worth watching: “Service Level”/“SLA” is used for at least three other, unrelated concepts elsewhere in the SAP portfolio.

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

1.1) What Is the Service Level?#

A Service Level exists to define, in one reusable record, how fast a Case must be handled and during which hours that speed is actually measured. It carries four Milestones — Response Due, Initial Review Due, Completion Due, Resolution Due — each with its own calculation anchor, duration, and optional extension, plus an embedded Operating Hours block that determines whether the clock pauses outside business hours or keeps counting through every calendar day. Once activated, a Service Level becomes selectable only as the target value inside a separate rules engine (Service Level Determination) — it never reaches out and picks itself for a Case.

Naming collision — “Service Level”/“SLA” is a quadruple-overloaded term across the SAP portfolio. At least four genuinely different things share this name: (a) SAP’s own contractual cloud-uptime Service Level Agreement document (sap.com → About → SAP Agreements → SAP Cloud Services Customers), covering platform availability commitments and unrelated to any in-app case data; (b) the classic SAP Cloud for Customer / Service Cloud V1 “SLA Setup” (Administrator → Service and Social → SLA Setup — a scoping-and-metrics process using Response Time / Resolution Time / Availability metrics); (c) SAP Solution Manager’s ITSM/ChaRM SLA (Service Profiles, IRT/MPT/OLA, configured via SOLMAN_SETUP — an on-premise, ABAP-stack ticket-management concept); and (d) the SAP Service Cloud V2 Service Level object covered in this article (Milestones + embedded Operating Hours, configured under Settings → Case Management → Service Levels). All four genuinely share Response/Resolution Time vocabulary, which makes this collision riskier to conflate than most other naming collisions covered elsewhere in this framework — confirm which of the four a piece of documentation, a support ticket, or a colleague’s comment is actually describing before applying it here.

Common misconception — Service Level is not Service Level Determination. Service Level (this article) is the SLA target definition itself — Milestones, Durations, and an embedded Operating Hours block. Service Level Determination (SC-A06-02) is a separate rules engine that decides which Service Level applies to a given Case, matching on inputs like Case Type and Priority Code, and requires activation after creation as its own configuration step. Service Level carries no field referencing Case Type, Priority, or any Determination Rule — the dependency runs one way: Service Level Determination consumes Service Level as an output/target value, never the reverse.

1.2) Milestones, Duration Types & Operating Hours#

Getting the difference between an hour-based and a day-based Duration wrong is not a cosmetic mistake — it changes whether the SLA clock pauses outside business hours or keeps ticking through nights, weekends, and holidays, and SAP documents the two behaviors as genuinely different calculation paths, not a rounding nuance.

Design principle — hour-based Durations respect Operating Hours; day-based Durations count full calendar days. If a Milestone’s Duration is entered in hours (or minutes/seconds), the system counts only time that falls inside the Service Level’s Operating Hours — the SLA clock effectively pauses outside business hours, so “24 hours” means 24 working hours, not 24 wall-clock hours. If Duration is entered in days (or months), the system uses the Working Day Calendar to decide which days count, but does not apply the Working Configuration’s specific time-of-day ranges — each qualifying day counts as one full calendar day regardless of when work actually happens on it. Supported Duration units are Day, Month, Hours, Minutes, and Seconds; choose the unit deliberately, since it changes the calculation path, not just the displayed number.

Common misconception — a Service Level record has no Priority field (V2). Unlike the classic V1 “SLA Setup,” a single V2 Service Level record cannot vary its Milestone targets by priority internally. If Gold-tier cases need a 2-hour Response Due and Silver-tier cases need an 8-hour Response Due, that requires two separate Service Level records — one per tier — not one record with a priority-dependent field. Priority Code only becomes relevant one layer up, as a match parameter inside a Service Level Determination rule (SC-A06-02) that selects which of the two records applies to a given Case.

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 Level "GOLD - Premium Support" (Status: Active)
   │        │
   │        ├── Milestones: Response Due (2 Hours), Initial Review Due (4 Hours),
   │        │               Completion Due (1 Day), Resolution Due (3 Days)
   │        │
   │        └── Operating Hours (embedded) ── references ──> Working Day Calendar "APAC-STANDARD"
   │                                                              │
   │                                                              └── linked Holiday Calendar "JP-HOLIDAYS-2026"
   │             Time Zone: Asia/Tokyo
   │             Working Configuration: Mon–Fri 09:00–18:00 (single slot)
   │
   ├── Service Level "SILVER - Standard Support" (Status: Active)
   │        │
   │        ├── Milestones: Response Due (8 Hours), Initial Review Due (1 Day),
   │        │               Completion Due (3 Days), Resolution Due (5 Days)
   │        │
   │        └── Operating Hours (embedded) ── references ──> Working Day Calendar "APAC-STANDARD" (shared)
   │
   └── Working Day Calendar "APAC-STANDARD" — shared master object, maintained under
            Settings → Calendar → Working Day Calendar (not created fresh per Service Level)

   Service Level Determination Rule "Auto SLA - Gold Tier"
      ── matches on (Case Type = "Customer Service Case" AND Priority Code = "01 - Immediate") ──>
      selects Service Level "GOLD - Premium Support"

Design principle — the Working Day Calendar is a shared, separately-maintained master, not a value entered fresh on each Service Level. Working Day Calendar (and its linked Holiday Calendar) is its own configuration object with its own fields (Working Calendar Name/Code, Valid From/To, applicable countries/regions, per-day toggles, First Day of Week) — a Service Level’s Operating Hours block only references it. Two Service Levels for the same region (Gold and Silver tiers, for example) typically point at the same Working Day Calendar while differing only in their Milestone Durations. This calendar object is also used elsewhere in the platform (confirmed on the equivalent SAP Sales Cloud V2 settings page; treat as shared infrastructure across Sales and Service Cloud V2 with medium confidence rather than a Service-Cloud-only object). Time Zone and Working Configuration, by contrast, are set directly on the Service Level’s own Operating Hours block, not referenced from elsewhere.

1.4) Integration with Other Master Data Objects#

A Service Level touches several other objects, but in two clearly different directions: it optionally references one master (Working Day Calendar) as its source, and it is the target that a downstream rules engine selects. 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) Source material confirms Service Levels follow the same draft-then-active lifecycle pattern seen elsewhere in this framework (Service Catalog, Service Category, Case Type), but the exact re-edit mechanism for an already-Active Service Level (e.g., whether a “Create New Version” action exists, as it does for Case Type) was not independently confirmed in this research pass — treat as likely but unconfirmed. (2) The Case-side field group attributed above to a “Case Escalation Metrics” view rests on a search-index summary only; the primary SAP Help Portal page could not be rendered during research, so treat those specific field names as medium confidence, not a confirmed screen layout. (3) Whether SAP Service Cloud V2 publishes a dedicated “SLA breach” event type to SAP Event Mesh could not be confirmed against a primary source — case lifecycle events are published to Event Mesh generally, but a specific SLA-breach event type is not asserted here.

Part 2: SC-Specific Field Details#

2.0) Scope of SC Ownership#

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

2.1) Service Level Header (Base Attributes)#

This is the identity record every Service Level has, regardless of which Milestones or Operating Hours it defines — get these fields right and the Service Level is correctly named, correctly statused, and ready to be selected as a Determination target.

2.2) Milestones#

Milestones are the actual SLA promise a Service Level makes — four due-dates, each independently configured, that together define how fast a Case must move through response, review, completion, and resolution.

2.3) Operating Hours#

Operating Hours is the block embedded directly on the Service Level record that decides whether an hour-based Duration’s clock pauses outside business hours — see Section 1.2 for the underlying calculation logic.

2.4) Case-Side Milestone Fields#

These are the read-only attributes written back onto the assigned Case as each Service Level Milestone completes — not fields configured on the Service Level record itself, but the observable result of it.

What to Read Next#

L1) Big Picture

L2-A) Master Data

L2-B) Transaction