JinJin48

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

July 19, 2026 · 20 min read

SAP Service Cloud Case Routing Rules

Case Routing is not one configuration screen with an Employee/Team/Queue dropdown — it is two independent decision tables, “Case Routing to Employee” and “Case Routing to Team,” each with its own decision table ID, its own rows, and its own single Result value. Both tables reuse, unchanged, the same generic rules-table engine documented for Service Level Determination (SC-A06-02): up to 15 columns configured via Adapt Columns, AND-within-a-row / OR-across-rows evaluation, top-to-bottom first-match-wins short-circuiting, row position as the only precedence signal, an explicit Activate step, and Excel export/import for bulk maintenance. What differs is only the output: Case Routing to Employee’s Result column populates Party Role 40 (“Processor”), while Case Routing to Team’s Result column populates Party Role 28 (“Service and Support Team”). This article also resolves two common points of confusion: there is no formal “Queue” object anywhere in the official documentation, and the AI-driven “Case Type Determination” feature is a completely unrelated capability despite the similar name.

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

1.1) What Is Case Routing (to Employee / to Team)?#

Case Routing exists to answer one operational question every time a Case is created or edited: given this Case’s field values, which employee — or which team — should own it? SAP Service Cloud answers this with two separate rules tables rather than one combined object: an administrator sets up “Case Routing to Employee” to assign an individual agent, and independently sets up “Case Routing to Team” to assign a service team. Neither table stores routing logic for the other; they are peers, not two modes of a shared screen, and each carries its own decision table ID.

Common misconception — there is no formal “Queue” routing target. Neither the Case Routing to Employee nor the Case Routing to Team screen exposes a “Queue” object as a Result value, and a full-text search of the official Solution Guide finds “queue” used only for unrelated integration/message queues (outbound topic queues, email retry queues) — never as a Case assignment target. The informal phrase “team queue,” seen in some training material, describes a workflow behavior — the list of Cases assigned to a team that a manager reviews or agents self-pick from — not a distinct, configurable object inside the rules table. Do not model or document a “Queue” column, Result value, or screen; the only two Result targets that officially exist are Processor (via Case Routing to Employee) and Service and Support Team (via Case Routing to Team).

Disambiguation — “Case Type Determination” is a different, unrelated AI feature. SAP Service Cloud’s Intelligent Services also include a capability called “Case Type Determination,” which uses NLP/AI to infer the Case Type field from a Case’s subject and description text — it has nothing to do with routing an already-typed Case to a person or team. The two features share only the generic word “Determination” in casual conversation; do not conflate AI-based Case Type inference with the decision-table-based Case Routing to Employee/Team mechanism covered in this article.

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

Both routing tables run on the exact same evaluation logic as Service Level Determination (SC-A06-02) — reusing it is not a coincidence but a documented, shared engine design, restated here so each article stands independently.

Design principle — row position is the priority field, independently per table. As with Service Level Determination, there is no numeric priority column to set or audit. Because Case Routing to Employee and Case Routing to Team are separate tables, each has its own independent row ordering — reordering rows in one has zero effect on the other’s evaluation sequence.

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 Routing to Employee Rule Table (Status: Active)
   │        │
   │        ├── Row 1: Case Type = "Customer Service Case" AND Category = "Billing"
   │        │            ── Result ──> Processor "Agent: Jane Tanaka" (Party Role 40)
   │        │
   │        └── Evaluated top-to-bottom, independently of the Team table below
   │
   ├── Case Routing to Team Rule Table (Status: Active)
   │        │
   │        ├── Row 1: Case Type = "Customer Service Case" AND Source = "Email"
   │        │            ── Result ──> Service and Support Team "Billing Support EMEA" (Party Role 28)
   │        │
   │        └── Evaluated top-to-bottom, independently of the Employee table above
   │
   ├── Party Schema "Standard Case Party Schema" — governs both Party Role 40 (Processor)
   │        and Party Role 28 (Service and Support Team); with "Enforce consistency with
   │        source party" enabled, the system keeps the assigned Processor and the assigned
   │        Service and Support Team aligned, auto-clearing or updating one when the other
   │        is manually changed outside a valid team structure
   │
   ├── Case Type "Customer Service Case" ── read by both tables as a match column value
   │        (no field on either rule table pointing back to Case Type as an owned object)
   │
   └── Category "Billing" / Source "Email" ── read by their respective rows as match column
            values (same one-directional read, no reverse reference)

Design principle — the two Result outputs are operationally linked via Party Schema, not via the routing tables themselves. Case Routing to Employee and Case Routing to Team never reference each other directly, and there is no shared “master” table between them. The link exists one layer up, in the Party Schema configuration: when “Enforce consistency with source party” is enabled for Party Roles 40 and 28, the system automatically corrects a manually-assigned agent who falls outside their team’s structure. This means a Case can, in principle, receive its Processor and its Service and Support Team from two entirely separate rule evaluations that happen to agree — or need reconciling by this consistency check when they do not.

1.4) Integration with Other Master Data Objects#

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

Scope notes: (1) No exhaustive, current, official list of selectable match columns exists for either table — the mechanism (Adapt Columns, any available Case field, up to 15 columns) is confirmed, but the only named example fields across all sources are Case Type, Category, Source/Channel, and (informally) Account. (2) Whether each routing table is scoped per Case Type/Case Template or is one single global table is not conclusively confirmed — the transport section’s reference to “decision table IDs… within the case template version” hints at per-template scoping, but the core configuration procedures describe only one screen per routing direction. Treat this as an open question. (3) No documented fallback/default behavior exists for a Case matching zero rows in either table — see the Section 1.3 hierarchy note and the design principle below. (4) The underlying rules-engine technology is officially termed a “decision table” in the transport section of the Solution Guide, resolving the earlier open question from SC-A06-02 about the mechanism’s official name; it is not named as BRFplus or any other named technology.

Design principle — a catch-all final row in each table is good practice, not a documented system default. No official source states what happens when a Case matches zero rows in Case Routing to Employee, zero rows in Case Routing to Team, or both. The only related data point is that “unassigned case count” is a tracked Analytics KPI, confirming an unassigned state exists and is monitored — but not that it is specifically caused by routing-rule non-match rather than some other cause. Do not state a specific fallback mechanism in the article or in configuration guidance; treat adding a final wildcard row per table as a recommended safety practice, and confirm actual no-match behavior in a sandbox tenant before assuming any specific fallback exists in production.

Part 2: SC-Specific Field Details#

2.0) Scope of SC Ownership#

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

2.1) Case Routing to Employee (Rule Table Configuration)#

This is the screen an administrator opens to route individual Cases to a specific human agent, distinct from — and configured entirely separately from — the Team table in Section 2.2.

2.2) Case Routing to Team (Rule Table Configuration)#

This is the sibling screen used to route Cases to a service team rather than an individual — reached via its own menu entry, not nested inside the Employee screen.

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

Each row is the actual, individually authored rule — the atomic unit of both routing tables, working identically in either one.

2.4) Row Sequence / Precedence#

This is the mechanic that determines which rule actually wins when a Case could theoretically match more than one row — tracked entirely separately for the Employee table and the Team table.

2.5) Activation State#

Editing either table is deliberately non-destructive to production behavior — nothing takes effect until an explicit step is completed, and the two tables’ activation states never affect one another.

2.6) Bulk Maintenance (Excel Export/Import)#

For rule tables that have grown large, editing row by row in the UI stops being practical — SAP provides the same offline path for both routing tables that it provides for Service Level Determination.

Prerequisite: Column structure must exist first — export/import is a row-value maintenance tool, not a column-design tool, and this holds independently for each of the two tables. 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