JinJin48

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

July 8, 2026 · 4 min read

SAP Fieldglass Certification

Certification is the second of two Phase 4 objects under MSP & Certification Settings — its sibling, MSP Company, is documented separately in FG-A05-01. Certification is Fieldglass’s compliance-tracking master data object: an Administrator defines the credential types the program needs to track (e.g. an information security certification, a background check, a safety qualification), along with each one’s expiration rule and whether it is a hard, Mandatory prerequisite (Compliance Required). Configuring it is optional: per the module’s own Required vs Optional Master classification, Certification applies only to tenants running an active compliance-tracking program. This article first covers the concepts shared across every Fieldglass process area Certification touches (Part 1) — including, in Section 1.3, why it is the most fully standalone master data object documented in this article series to date — then details every field a Fieldglass Administrator configures for it (Part 2).

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

1.1 What Is the Certification?#

Certification is the record that formally defines a single compliance credential or license type the program tracks, along with the rule that determines whether that credential expires and whether holding a valid one is mandatory. It does not itself define who is eligible to work, what rate applies, or how a requisition is approved — those remain governed by the objects covered in earlier Phase 1–3 articles. Certification simply layers a compliance check on top of the workers and transactions that already flow through the platform.

1.2 Certification Compliance Models Compared#

Certification does not carry a formal “Type” field the way Contingent Type or SOW Type do — instead, its Compliance Required field selects between two enforcement models, and getting this setting wrong either creates a silent compliance gap or an unnecessary onboarding blocker.

Design principle: Confirm with the client’s compliance or legal stakeholder which credentials are truly mandatory before configuration — flagging a certification as Informational when the underlying contract or regulation actually requires it as Mandatory creates a compliance gap that Fieldglass will not catch on its own.

1.3 Organizational Levels and Data Hierarchy#

Zone D — Job Posting · SOW · MSP (this object’s own zone): Certification is a standalone tenant-level node at Row 4 of Zone D — it owns no children and carries no outbound line or chip to any other Zone D object, and — unlike MSP Company one row above it — no inbound chip from any other Zone D node either.

Data hierarchy with a concrete example

Zone D position (standalone tenant-level object — no children, no outbound chip,
no inbound chip from any other Zone D node)

Certification "CERT-ISO27001" — ISO 27001 Information Security  ◄── this article
Certification "CERT-BG-CHECK" — Background Check / Drug Screening  ◄── this article

No real-world master data prerequisite documented in the Setup Flow or ER Diagram
(Setup Flow: "25. Certification ← (-)"; ER Diagram: "Certification (独立)") —
genuinely standalone, unlike MSP Company's real Supplier dependency documented in FG-A05-01

Certification sits in Zone D of the Fieldglass Master Data Landscape as a standalone Row 4 card, below Contingent Type, SOW Type, and MSP Company — but unlike all three, it carries neither an outbound chip to another Zone D object nor an inbound chip from one. The corrected landscape confirms this directly: no solid line connects Certification to MSP Company (the two Phase 4 objects are configured independently of one another, exactly as already stated from the MSP Company side in FG-A05-01), and no dashed reference arrow points into or out of the Certification node from any other zone.

The module’s own Setup Flow entry — “25. Certification ← (-)” — and its ER Diagram entry — “Certification (独立)” — both confirm Certification has no documented real-world master-data prerequisite. This differs meaningfully from MSP Company (FG-A05-01), whose Supplier dependency is real but simply not yet drawn as a cross-zone chip on the current landscape; Certification genuinely has no prerequisite documented anywhere in the source data. It is the most fully standalone object covered in this article series to date — a tenant can create Certification records the moment the module is provisioned, with no other master data object needing to exist first.

1.4 Integration with Other Master Data Objects#

Certification does not attach to other master data objects through any formal, field-level reference documented in the Master Data source — but that does not mean it operates in isolation from the rest of the program. Its practical relationships run through transaction-level compliance checks and administrative grouping rather than configured object links.

Part 2: FG-Specific Field Details#

2.0 Scope of FG Ownership#

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

2.1 Certification — Identification & Classification#

Certification carries the fields that identify the record and label it consistently across Admin, compliance reporting, and onboarding checks.

2.2 Compliance & Expiration Rules#

Compliance & Expiration Rules carries the three fields that determine whether a credential lapses, whether it blocks onboarding, and how far in advance the program is warned before it does — the enforcement core of the Certification record.

What to Read Next#

L1) Big Picture

L2-A) Master Data

L2-B) Transaction