JinJin48

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

July 19, 2026 · 16 min read

SAP Service Cloud Service Level Determination

Service Level Determination is not a second place where SLA times live — it is a decision table that decides which already-activated Service Level (SC-A06-01) applies to a given Case, matching on inputs such as Case Type and Priority Code and outputting a single Service Level as the result. Administrators configure it as a rules table of up to 15 columns, evaluated top to bottom with the first fully-matching row winning; row position, not a numeric priority field, is what determines precedence. The exact same mechanism — Adapt Columns, AND-within-row/OR-across-rows, top-to-bottom first match, an explicit Activate step — is reused elsewhere in Case Management for Case Routing to Employee and to Team, so this article also flags where Service Level Determination is one specific instance of a shared, generic pattern rather than a bespoke SLA engine. It also draws a hard line between this feature and an unrelated, similarly-named generic “Determination” configuration framework elsewhere in the product, which shares only a word, not a mechanism.

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

1.1) What Is the Service Level Determination Rule?#

A determination rule exists to answer one question every time a Case is created or edited: given this Case’s field values, which of the several possible Service Level records should govern its SLA clock? It does this by evaluating a table of administrator-defined rows against the Case, applying the Service Level named in the first row that matches. The rule itself stores no SLA times, no Milestones, and no Operating Hours — all of that lives on the Service Level record it selects (SC-A06-01).

Common misconception — this is not the same “Determination” as the generic Determination framework elsewhere in SAP Service Cloud. SAP Service Cloud also has a separate, generic configuration framework literally called “Determination” — structured as Header (name, triggering event) + Condition Block + Assignment Block, with Pre Hook (defaults a field, overridable) and Post Hook (forces a field, non-overridable) execution points, typically shown defaulting or forcing a Case’s Priority based on Case Type and Origin. No source ties Service Level assignment to this Header/Condition/Assignment framework. Service Level Determination instead uses the plain decision-table mechanism it shares with Case Routing to Employee/Team. The two features share a name fragment only — do not describe Service Level Determination as running on Pre/Post Hooks, and do not describe the generic Determination framework as SLA-related.

1.2) Rule Logic: Match Columns, Evaluation Order & Activation#

Getting the AND/OR direction backwards is the single most common way to misconfigure this table: every value inside one row must all be true together, while separate rows are alternatives to each other — and only the first alternative that fires actually applies.

Design principle — row position is the priority field. Business stakeholders coming from tools with an explicit numeric “Priority” column on a rules table need to unlearn that expectation here: in Service Level Determination, the row’s physical position in the table is its priority, enforced purely by top-to-bottom, first-match-wins evaluation. There is no independent priority number to set or audit separately from the row order itself.

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 Determination Rule Table "Case SLA Assignment" (Status: Active)
   │        │
   │        ├── Row 1: Case Type = "Customer Service Case" AND Priority Code = "01 - Immediate"
   │        │            ── Result ──> Service Level "GOLD - Premium Support"
   │        │
   │        ├── Row 2 (catch-all, recommended practice — not a documented system default):
   │        │            Case Type = "*" AND Priority Code = "*"
   │        │            ── Result ──> Service Level "SILVER - Standard Support"
   │        │
   │        └── Evaluated top-to-bottom: Row 1 short-circuits the table for any matching Case;
   │             Row 2 is only reached when Row 1's conditions are not met
   │
   ├── Service Level "GOLD - Premium Support" (Status: Active) ── referenced as Row 1's Result value
   │
   ├── Service Level "SILVER - Standard Support" (Status: Active) ── referenced as Row 2's Result value
   │
   ├── Case Type "Customer Service Case" ── read by Row 1 as a match column value (no field on the
   │        rule pointing back to Case Type as an owned object — the rule only reads its current value)
   │
   └── Priority Code "01 - Immediate" (one of a fixed set of four priority codes) ── read by Row 1
            as a match column value (same one-directional read, no reverse reference)

Design principle — a catch-all final row is good practice, not a documented system default. No official source states what happens when a Case matches zero rows in the table — whether it is left with no assigned Service Level (and therefore no SLA due dates), whether some implicit default applies, or whether this is simply undefined behavior administrators are expected to prevent. Treat adding a final wildcard row (as shown in Row 2 above) as a recommended safety practice, and confirm actual no-match behavior in a sandbox tenant before assuming any specific fallback exists in production.

1.4) Integration with Other Master Data Objects#

Service Level Determination touches several other objects, but always in the same two directions: it reads Case field values as match inputs, and it writes a single Service Level as its Result. The table is explicit about which relationships are sourced and which remain open items from the research pass.

Scope notes: (1) No current, exhaustive, official field list confirms every selectable match column for the V2 rules table beyond Case Type and Priority Code — the official guide describes the mechanism (Adapt Columns, any available Case field, up to 15 columns) without enumerating a fixed default set; broader field lists appearing in community material or the classic product’s official guide (service type, product category, service category, country/region, customer group) should be treated as illustrative, not a confirmed current V2 list. (2) The underlying rules-engine technology (e.g., whether it is implemented on BRFplus or a proprietary business-rules service) is not stated in current SAP Service Cloud Version 2 documentation and should not be asserted. (3) Fallback behavior for zero matching rows is undocumented — see the Section 1.3 design principle.

Part 2: SC-Specific Field Details#

2.0) Scope of SC Ownership#

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

2.1) Rule Table Configuration (Adapt Columns)#

Before any row can be entered, the table’s own column structure has to be set up — this is the one-time (though revisitable) step that decides which Case fields are even available to match against.

2.2) Rule Row (Match Columns + Result Column)#

Each row is the actual, individually authored rule — the atomic unit of the whole feature.

2.3) Row Sequence / Precedence#

This is the mechanic that determines which rule actually wins when a Case could theoretically match more than one row.

2.4) Activation State#

Editing this table is deliberately non-destructive to production behavior — nothing takes effect until an explicit step is completed.

2.5) Bulk Maintenance (Excel Export/Import)#

For rule tables that have grown large, editing row by row in the UI stops being practical — SAP provides an offline path for exactly this case.

Prerequisite: Column structure must exist first — export/import is a row-value maintenance tool, not a column-design tool. Attempting to introduce a brand-new match field via an imported file without first running Adapt Columns in the UI is not a documented workflow.

What to Read Next#

L1) Big Picture

L2-A) Master Data

L2-B) Transaction