JinJin48

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

July 19, 2026 · 15 min read

SAP Service Cloud Installed Base

An Installed Base in SAP Service Cloud is “a hierarchical arrangement of items installed at your customer’s location” — a container record created manually from a worklist that other objects then attach to, directly or through each other. Its own field template carries no parent-pointer field of any kind and no Warranty field, which — combined with the confirmed Parent Installed Base UUID field present on Functional Location, Product Installation Point, and Registered Product — makes Installed Base the root of a flexible, multi-level tree rather than the midpoint of a fixed two-branch model. It is also, unlike Warranty, one of four object types with its own direct, first-class reference from Case, via a dedicated “Case Installed Bases” subentity. This article maps that structure precisely, covers the customer and party-role fields entered when an Installed Base is created, and flags where a naming collision or a documentation gap should change how you build with it.

Part 1: Installed Base — Core Concepts (All Modules)#

1.1) What Is the Installed Base?#

An Installed Base exists to answer one question: what products and locations belong to this customer, arranged hierarchically? SAP Service Cloud answers this with a container record — Installed Base — that other item-level objects attach to, either directly or through one another, rather than a record that reaches out and attaches itself to something else. The Feature Scope Description confirms Installed Base can be viewed from either direction — “by customer or product” — consistent with it acting as an aggregation point over whichever product-bearing items a given customer’s site actually has installed.

Naming collision — “Installed Base” means at least two unrelated things elsewhere in the SAP portfolio. This object shares nothing but a name with: (1) SAP S/4HANA (on-premise) and classic ECC “Installed Base Management (CS-IB)” — a Plant Maintenance / Customer Service application component (table IBIB) that groups Equipment, Functional Location, and serialized Material into a common installed base via a tree-control maintenance screen, with a hard constraint that “a piece of equipment, functional location, or material with serial number may only exist in one installed base at any one time”; this on-premise object is also the one historically shared with classic SAP CRM Service (WebClient, IB5x-range transactions); and (2) SAP Field Service Management’s own “Assets/Installed Base” concept, maintained in its own separate cloud data model and REST API for service-order scheduling/dispatch context. Both are architecturally distinct products from SAP Service Cloud Version 2’s Installed Base object, despite the shared term. Not a collision: SAP Cloud for Customer (C4C), the ticket-based predecessor product, has what is functionally the same Installed Base concept researched here — direct product lineage across SAP’s Case/ticket-based cloud service generations (C4C → SAP Sales and Service Cloud → SAP Service Cloud Version 2), not a separate, same-named concept.

1.2) Customer Type and Party-Role Variations#

At creation, an admin selects only “the type of the customer” alongside Description, Account, and Contact — but the full field template exposes five distinct party-role slots, each of which can independently point to either a corporate Account or an Individual Customer. Getting the wrong role populated (or leaving a role unpopulated when the business actually needs it) means invoices routed to the wrong entity or field-service visits scheduled against the wrong site contact.

Design principle: The primary Account or Individual Customer entered at Installed Base creation is not automatically the Payer, Bill-To, or Ship-To party — each of those roles (plus Owner) is a separately populated field pair on the same record, and only the base Account/Contact pairing is mandatory.

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)
   │
   └── Account "ACC-77410 — Acme Manufacturing K.K." (base customer party role)
          │
          └── Installed Base "IB-40210 — Acme Mfg, Yokohama Plant, Packaging Line 2"
                 │        (ROOT — its own field template carries no Parent-* field
                 │         and no Warranty field; it is never the referencing/child
                 │         side of any relationship)
                 │
                 ├── Functional Location "FL-8801 — Packaging Robot Cell"
                 │        (Parent Installed Base UUID = IB-40210)
                 │        │
                 │        └── Product Installation Point "PIP-3305 — Motor Drive Unit"
                 │                 (Parent Installation Point UUID = FL-8801 — illustrates
                 │                  that an Installation Point can nest under a Functional
                 │                  Location instead of directly under Installed Base)
                 │
                 └── Registered Product "RP-90215 — Serial# CNV-2024-118"
                          (Parent Installed Base UUID = IB-40210 — attached directly,
                           the other supported nesting pattern)

Case "CS-500311 — Conveyor motor overheating, packaging line down"
     ── references ──> Installed Base "IB-40210"
          (direct field-level link via the "Case Installed Bases" subentity —
           Installed Base ID field)

Design principle — Installed Base is the sole root of a flexible tree, not one branch of a fixed two-level model. Functional Location, Product Installation Point, and Registered Product each carry all three parent-pointer fields (Parent Installed Base UUID, Parent Registered Product UUID, Parent Installation Point UUID) — only one of which is populated at a time in practice — meaning any of the three item types can nest directly under an Installed Base, or one level deeper under another item. The Setup Guide’s own creation guidance even frames Functional Location, Registered Product, and Product Installation Point as UI-level “categories” of one broader underlying “Installation Point” concept, differentiated mainly by which tab a record is displayed in — a well-evidenced nuance, though not fully cross-confirmed by a single unifying technical statement elsewhere.

1.4) Integration with Other Master Data Objects#

Installed Base does not stand alone — it is the container the flexible item-tree attaches to, the party-role anchor Account and its billing/shipping variants reference, and one of only four object types with a genuine direct reference from Case.

Genuine direct relationship, not a myth to bust. The Warranty sibling article found Case has no direct field-level link to Warranty. Installed Base is the opposite case: the “Case Installed Bases” subentity is a real, confirmed, first-class link at the data-model level, in the same structural family as Case’s direct links to Functional Location, Product Installation Point, and Registered Product. Do not assume Installed Base only reaches a Case indirectly through its contained items — it has its own direct reference.

Coverage gap — no confirmed S/4HANA replication scenario for Installed Base itself. All documented creation guidance for Installed Base describes a manual, in-app worklist action only. Do not assert that Installed Base is commonly created via automated S/4HANA replication in a given implementation; treat manual creation as the documented default rather than an absolute claim that no customer-specific integration exists.

Part 2: SC-Specific Field Details#

2.0) Scope of SC Ownership#

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

2.1) Core Identification & Status#

These fields establish which Installed Base this is and whether it is currently active — every party-role, address, and assignment field below only matters once these are set.

2.2) Customer & Party Roles#

These fields place the Installed Base against the correct customer and — where the business needs it — a separate owner, payer, or delivery party, as introduced in Section 1.2.

2.3) Address & Geolocation#

These fields record the physical site the item hierarchy actually sits at — the location a field technician is dispatched to when a Case is raised against this Installed Base.

2.4) Service Assignment#

These fields determine who is accountable for the site once a Case is raised against it — getting them wrong routes work to the wrong team before the Case Routing Rule configuration is even evaluated.

2.5) Case Linkage (Case Installed Bases Subentity)#

These two fields live on the Case side of the relationship, not on Installed Base itself — but they are the actual mechanism that gives Case a direct, first-class reference to an Installed Base, so they belong in this article’s field-level scope.

Prerequisite: This subentity is structurally identical in form to the confirmed “Case Functional Locations,” “Case Registered Products,” and “Case Product Install Points” subentities — all four item/container types have their own direct Case join-subentity; none requires going through another object to be linked to a Case.

2.6) Work Center & Access Control#

Like the other master-data objects in this batch, access to the Installed Bases worklist is governed entirely through Business Role assignment, not through any field on the Installed Base record itself.

What to Read Next#

L1) Big Picture

L2-A) Master Data

L2-B) Transaction