JinJin48

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

July 15, 2026 · 12 min read

SAP FSM Crew

Crew is FSM’s optional master record for a dispatchable team — a lead technician plus one or more member technicians grouped together for jobs that genuinely require more than a single field service resource, such as an installation, a confined-space job, or any Service Call demanding several certified skills at once. Unlike Skill, Work Time Pattern, and Region, which are configured independently before being assigned, Crew has exactly one true prerequisite: Person/Technician (FSM-A04-04) records must already exist for both the Lead and every Member before a Crew can be created — Crew stores no fields of its own beyond identification and this Lead/Member reference list. Crew is flagged as an optional master, used only when the business actually dispatches work to teams rather than to individual technicians; a tenant that never assigns more than one technician to a Service Call has no need to configure it. Crew is the fifth object in the Technician Management domain (Phase 3, Zone C) covered in this series, alongside Skill (FSM-A04-01), Work Time Pattern (FSM-A04-02), Region (FSM-A04-03), Person/Technician (FSM-A04-04), and Absence (FSM-A04-06). This article maps every field FSM consultants configure on a Crew record, and how those fields connect back to the Person/Technician records that make up its Lead and Members.

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

1.1 What Is Crew?#

A Crew represents a single, named team of field service technicians — one designated Lead plus any number of Members, grouped together so a dispatcher can assign a whole team to a Service Call in one step rather than assigning each technician individually. It is a deliberately thin master: it carries no Skill, Region, or Work Time Pattern fields of its own, because every one of those properties already exists on the individual Person/Technician records that make up the team.

1.2 Crew Composition Patterns#

Crew carries no separate classification field of its own — Crew ID, Crew Name, Crew Lead, and Crew Members are the entire record, and any of the composition patterns below is expressed purely through who is added as Lead and Members. What varies in practice is why a team was formed and how long it is expected to persist, which shapes how often consultants expect its membership to change.

Design principle: Crew has no dedicated classification field — composition pattern is purely an operational choice expressed through who is added as Lead and Members, never through a coded Crew Type value.

1.3 Organizational Levels and Data Hierarchy#

Data hierarchy with a concrete example (Zone C · Technician Management — tenant-level; FSM has no Company Code / Plant scoping above these objects)

Client (FSM Tenant)
   │
   ├── Skill SK-ELEC — Electrical Work L3                 (configured independently; tenant-level catalog)
   ├── Work Time Pattern WTP-STD — Mon–Fri 09:00–18:00     (configured independently; tenant-level catalog)
   ├── Region RG-KAN — Kanto (Asia/Tokyo)                   (configured independently; tenant-level catalog)
   │
   ├── Person / Technician P-001 — Hanako Yamada (Plannable = Yes)   (leads Crew CR-TOK-A)
   ├── Person / Technician P-002 — Kenji Sato    (Plannable = Yes)   (member of Crew CR-TOK-A)
   └── Person / Technician P-003 — Aoi Tanaka    (Plannable = Yes)   (member of Crew CR-TOK-A)

Crew CR-TOK-A — Tokyo Team A (reference — groups technicians, does not own any Person record):
   Crew CR-TOK-A ── led by ──▶ Person / Technician P-001 — Hanako Yamada      (exactly one Lead)
   Crew CR-TOK-A ── has member ──▶ Person / Technician P-002 — Kenji Sato      (N:M — a technician can belong to more than one Crew)
   Crew CR-TOK-A ── has member ──▶ Person / Technician P-003 — Aoi Tanaka      (N:M)
   (The Crew record itself owns only Crew ID, Crew Name, and this Lead/Member reference list — Skill, Region,
   and Work Time Pattern all remain properties of the individual Person/Technician records, never of the Crew.)

Absence ABS-P001 — Annual leave, 2024-08-10–2024-08-16 (reference; attaches to a Person, NOT to the Crew directly):
   Absence ABS-P001 ── blocks ──▶ Person / Technician P-001
   (Registering an Absence for the Lead or any Member blocks only that individual's own capacity — it does not
   deactivate the Crew record or block the remaining members from being dispatched.)

Skill Requirement SR-EQ001 — Requires a Skill on an Equipment (cross-zone; attaches to Equipment, NOT Crew):
   Skill Requirement SR-EQ001 ── requires ──▶ Skill SK-ELEC
   Skill Requirement SR-EQ001 ── applies to ──▶ Equipment EQ-001 (Zone B)
   (Matched against each individual Crew member's own assigned Skills by Assisted Scheduling at dispatch time —
   a per-Person run-time comparison, not a stored field on either Crew or Skill Requirement.)

Design principle: Crew is a reference relationship, not containment — the Lead and every Member are independent Person/Technician records configured first, and the Crew record itself stores only Crew ID, Crew Name, and the reference list pointing to them. Membership is N:M: the same technician can lead one Crew while being a plain Member of another, and can belong to more than one Crew depending on tenant configuration. Absence and Skill Requirement both attach to Person/Technician, not to Crew — the Crew record carries no separate Absence or Skill Requirement field of its own.

1.4 Integration with Other Master Data Objects#

Crew does not stand alone. Nearly every property that matters about a Crew is actually a property of the individual Person/Technician records it references, not of the Crew record itself.

Part 2: FSM-Specific Field Details#

2.0 Scope of FSM Ownership#

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

2.1 Core Identification#

These two fields are the whole identity of a Crew record — FSM keeps this master deliberately lean, with the actual team composition living in the fields covered in the next section.

2.2 Team Composition#

These two reference fields are the entire substance of a Crew — everything the team is capable of, and everywhere it can cover, traces back to exactly these two lists.

2.3 Assignment & Usage Linkage#

A Crew has no effect until it has a Lead, at least the beginnings of a Member list, and a dispatcher who selects it on the Planning Board. These are the linkage facts consultants check most often when a crew-level dispatch decision looks wrong.

Prerequisite: A Crew with no Lead assigned should not be used for dispatch — most tenant configurations expect at least a Lead in place before the Crew appears as a selectable resource on the Planning Board.

What to Read Next#

L1) Big Picture

L2-A) Master Data

L2-B) Transaction

Zone crop source: 04-fsm-a01-master-landscape.png (mtime: 2026-07-15 11:04:20, re-verified 2026-07-15 fix run)