JinJin48

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

July 17, 2026 · 10 min read

SAP Service Cloud Business User

The Business User is SAP Service Cloud’s master record for a system login — the credential a person actually uses to sign in and work cases, as distinct from the Employee record that describes who that person is inside the service organization. It cannot exist without an Employee already in place: Business User is created FROM an Employee record, and it is assigned one or more Business Roles (N:M) to determine what that login can see and do. Unlike Employee, it never references Organizational Unit or Team directly — any organizational context it appears to carry is inherited only through the Employee record it is linked to. This article maps its dependencies, its relationship to the other Employee & Org masters, and every field administrators configure when provisioning or reviewing system access.

Part 1: Business User — Core Concepts (All Modules)#

1.1 What Is the Business User?#

The Business User represents a system credential — not a person, and not a permission set on its own, but the login record that ties a specific Employee to a specific set of Business Roles. It exists so that system access can be granted, revoked, or reassigned independently of the underlying Employee record and independently of how access rights themselves are defined, rather than conflating “who this person is” with “what this login can do.”

1.2 Business User Access Patterns#

Service Cloud does not deliver a fixed “user type” field — the practical patterns below describe how a Business User record is actually configured and maintained once it exists. Getting this wrong either leaves a login over-scoped with roles nobody needs, or leaves a genuine agent unable to work the cases their job requires because a role assignment or the login itself was never completed.

Design principle: Grant only as many Business Roles as the underlying Employee’s actual job requires — a Multi-Role User accumulated through years of ad-hoc “just add this role too” requests is the most common source of an access review finding nobody can fully explain.

1.3 Organizational Levels and Data Hierarchy#

Data hierarchy with a concrete example (Zone A · Employee & Organization — tenant-level; SAP Service Cloud has no Company Code / Plant scoping above this)

Client (SAP Service Cloud Tenant)
   │
   └── Organizational Unit "SVC-ORG-001" — Service Dept (3-level hierarchy: HQ → Dept → Section)
          │
          ├── Employee "EMP-001" — Taro Yamada (external sync from SuccessFactors Employee Central)
          │      │
          │      └── Business User "YAMADA01" — system login for EMP-001
          │
          └── Team "SVC-TEAM-01" — Technical Support (5 members)

Business Role "SVC_AGENT" — Service Agent · Standard (independent master, no prerequisite)
Business User "YAMADA01" ── assigned to ──> Business Role "SVC_AGENT"
Team "SVC-TEAM-01" ── references ──> Employee "EMP-001" (team lead / member)

Design principle: Business User is the one Phase 1 master with a hard prerequisite on Employee — login “YAMADA01” cannot be created until Employee “EMP-001” already exists. Its Business Role assignment is a separate, independent dependency: both the Employee link and at least one Business Role must be in place before the login is fully functional, but neither one requires the other to exist first.

1.4 Integration with Other Master Data Objects#

Business User does not stand alone — it has exactly two direct connections, to Employee and to Business Role, and reaches everything else in the Employee & Org phase only second-hand.

Part 2: SC-Specific Field Details#

2.0 Scope of SC Ownership#

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

2.1 Core Identification & Credentials#

These fields establish which login this is, how it signs in, and whether it currently accepts sign-in at all — every linkage and role-assignment field below only matters once these are set.

2.2 Employee Linkage & Validity#

These fields tie the login to the one Employee it represents and bound the period during which that login is valid — getting the link right at creation time avoids a login pointing at the wrong person later.

2.3 Business Role Assignment#

These fields determine what this specific login is actually permitted to see and do — everything defined on the Business Role (SC-A02-03) side only takes effect once the assignment recorded here is in place.

What to Read Next#

L1) Big Picture

L2-A) Master Data

L2-B) Transaction