JinJin48

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

July 8, 2026 · 9 min read

SAP Fieldglass Site

The Site is the top-level location master in SAP Fieldglass Company Structure — it establishes where contingent labor work is performed and anchors the address, currency, time zone, and rule-scope defaults that ripple through nearly the entire Contingent Labor and SOW transaction flow. Every other object in the Phase 1 setup order builds on it: Location narrows a Site down to a specific floor or work area, Business Unit and Cost Center track the requisitioning organization and its budget, and later, Rate Grid (Phase 3) reads the Site to vary pricing by location. This article maps the Site’s core concepts across all Fieldglass capability areas (Part 1), then details every field an administrator configures when creating and maintaining Site records (Part 2).

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

1.1 What Is the Site?#

The Site represents a physical or logical business location in SAP Fieldglass — typically an office, plant, project site, or other place where contingent workers actually perform work, or from which a requisitioning organization operates. It is the first object created in the Phase 1 Company Structure setup sequence and has no upstream master data dependency; every other Company Structure object is created after it, and in the case of Location, directly under an existing Site.

1.2 Site Scope Dimensions#

Site does not carry a formal “Site Type” field the way some Fieldglass masters carry a Type code — instead, its influence shows up as a set of downstream scope dimensions that every requisition raised against it inherits by default. Getting the Site model wrong at design time (e.g., treating it as a loose location label rather than a jurisdiction and rule boundary) is a common source of rework once approval routing or tax handling issues surface post-go-live.

Design principle: Model Sites around legal-entity and tax boundaries first, convenience groupings second — Site drives compliance-critical defaults, so treating it as a loose “location tag” creates downstream compliance gaps that are expensive to unwind after go-live.

1.3 Organizational Levels and Data Hierarchy#

Data hierarchy with a concrete example

Tenant "WorkingNet" (client-level scope)
│
├── Business Unit "BU-ENG" — Network Engineering
│      └── Business Unit "BU-NETDESIGN" — Network Design (child of BU-ENG)
│
├── Cost Center "CC-1001" — flat financial-tracking master (not hierarchical)
│
└── Site "SITE-CHI" — Chicago, US  ◄── this article
       └── Location "LOC-CHI-01" — Chicago HQ Floor 3

Site sits directly under the Tenant, as a sibling of Business Unit and Cost Center — not nested inside either of them. Business Unit is the only hierarchical object in this zone (a Business Unit can have child Business Units, as shown by BU-NETDESIGN under BU-ENG); Cost Center is a flat, non-hierarchical financial-tracking master. Site’s own hierarchy is shallow: it owns Location directly (1:N) and nothing else nests underneath it organizationally — Rate Grid, Job Posting, and other objects that reference a Site do so as a cross-reference (see Section 1.4), not as an organizational child.

Site is also the target of a cross-zone reference from Zone C: the Rate Grid card there notes that Rate Grid varies by a Site in Zone A.

1.4 Integration with Other Master Data Objects#

The Site record does not stand alone — it is the anchor point that several other Phase 1–3 objects, and one external system, reference.

Part 2: FG-Specific Field Details#

2.0 Scope of FG Ownership#

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

2.1 Basic Identification & Address#

These fields uniquely identify a Site and are required before any child Location, rule scope, or downstream reference can be configured against it.

2.2 Locale & Financial Defaults#

These two fields set the baseline currency and time reference that every requisition, rate, and approval SLA calculated against this Site inherits by default.

2.3 Site Rules & Program Scope#

Site Rules let a specific Site override or narrow the Program-default configuration — the practical translation of the scope dimensions described in Section 1.2 into concrete, per-Site settings.

Prerequisite: Site must exist and be Active before Location, Rate Grid, or any Site-scoped Approval Rule/Distribution List that references it can be configured.

What to Read Next#

L1) Big Picture

L2-A) Master Data

L2-B) Transaction