JinJin48

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

July 15, 2026 · 10 min read

SAP FSM Contact

Contact is FSM’s master record for an individual named person associated with a Business Partner (Customer) — a facility manager, a site administrator, or any other person a dispatcher or technician may need to reach. It is always a child record of a Business Partner: a single Business Partner can carry any number of Contacts, each distinguished by role and communication details, and Contact itself has no further sub-objects of its own. This article maps every field FSM consultants configure and maintain when creating a Contact record, and how those fields connect Contact back to the Business Partner and Address masters that sit alongside it in Phase 1 (Customer Management).

Part 1: Contact — Core Concepts (All Modules)#

1.1 What Is Contact?#

Contact represents a specific, named individual tied to a customer — not the customer organization itself (that is Business Partner), and not a physical location (that is Address). It exists so that FSM always has a real person’s name and communication details on file whenever a technician or dispatcher needs to reach someone at the site, rather than relying on a generic company phone number.

1.2 Contact Role and Function#

A single Business Partner in FSM commonly has more than one Contact on file — a facility manager, a billing administrator, an emergency after-hours contact. The Contact Role (or Function) field is what lets dispatchers and technicians tell these apart at a glance, and getting it wrong risks calling the wrong person when something urgent comes up on site.

Design principle: Contact Role is a configurable field, not a fixed SAP-delivered picklist — align the value list with how the client’s service desk actually triages incoming calls, rather than carrying over a generic template unchanged.

1.3 Organizational Levels and Data Hierarchy#

Data hierarchy with a concrete example (Zone A · Customer Management — tenant-level; FSM has no Company Code / Plant scoping above Business Partner)

Client (FSM Tenant)
   │
   ├── Business Partner BP-001 — ABC Corp (Customer)
   │      │
   │      ├── Contact CT-A — Taro Tanaka, Facility Manager
   │      └── Address AD-A — 1-1 Marunouchi, Tokyo
   │
   └── Business Partner BP-002 — XYZ Ltd (Customer)
          │
          ├── Contact CT-B — Hiro Suzuki, Ops Lead
          └── Address AD-B — 2-2 Umeda, Osaka

Design principle: Contact is a tenant-level (client-level) child record of Business Partner — there is no Company Code / Plant hierarchy involved. Contact and Address are siblings under the same Business Partner; they do not reference each other directly, they are simply both filed under the same parent.

1.4 Integration with Other Master Data Objects#

Contact does not stand alone — it is filed under a Business Partner and is picked up whenever FSM’s other objects need a named person to reach.

Part 2: FSM-Specific Field Details#

2.0 Scope of FSM Ownership#

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

2.1 Core Identification & Business Partner Assignment#

These fields establish who this person is and which Business Partner the Contact record is filed under — every other field on Contact only makes sense once these two are set.

2.2 Communication Details#

These are the fields dispatchers and technicians actually use to reach the Contact — accuracy here has a direct, same-day operational impact.

2.3 Role, Function & Department#

Because a Business Partner commonly has more than one Contact on file, these fields are what let a dispatcher pick the right one for a given situation rather than defaulting to whichever record happens to be listed first.

2.4 Status & Site Notes#

These fields round out the Contact record with lifecycle and practical on-site context that doesn’t fit cleanly into identification, communication, or role.

What to Read Next#

L1) Big Picture

L2-A) Master Data

L2-B) Transaction