Why Validations Exist in MDG and How They Fit the Governance Flow

Explanation

Validations in SAP Master Data Governance exist to protect the quality, consistency, and compliance of master data before it becomes active or is distributed to downstream systems. Unlike a plain field-level check hardcoded in a UI, a validation in MDG is a governed business rule that is evaluated against the current state of the entity being processed inside a change request (CR). Because governance in MDG is built around change requests that move through a workflow (create, edit, review, approve), validations are the mechanism by which an organization enforces mandatory business logic consistently, regardless of who created the request or which UI configuration they used. Technically, most validation rules in current SAP MDG implementations are modeled using BRF+ (Business Rule Framework plus), which is exposed to MDG through rule types assigned to specific entities in the data model (for example a business partner, material, or a custom governance object). A validation rule typically expresses a condition (an expression, decision table, or similar BRF+ construct) that evaluates one or more attributes of the entity and produces a result: either the data passes silently, or a message is raised. The severity of that message (information, warning, or error) determines what happens next. An error-level validation message blocks the change request from moving forward in the workflow step where it fired, forcing the requester or steward to correct the data. A warning is shown but does not block progress. This severity behavior is central to how validations are used as a governance control rather than a suggestion. It is important to distinguish validations from derivations. Derivations calculate or default values (for example deriving a region code from a postal code), and they run to populate or adjust data automatically. Validations, in contrast, do not change data; they only assess it and communicate a result. In the standard MDG processing sequence, derivations generally run before validations so that any auto-populated values are already present when validation logic evaluates the record. This ordering matters because a validation rule written naively without accounting for derivation timing may fire against a field that has not yet been populated, producing false positives or false negatives. Validations are configured against the MDG data model, meaning a consultant assigns the rule to an entity and, where the data model supports it, to specific usages or processing steps (create, change, or both). This lets an organization apply stricter rules during initial creation than during minor updates, or vice versa, depending on business risk. Validations also typically respect the active/inactive area concept in MDG: a validation can be scoped to fire only when relevant attributes are actually touched in the current change request, which avoids unnecessary reprocessing of unrelated data. From a business perspective, validations are how governance teams encode policy: mandatory tax classification for certain countries, disallowed combinations of plant and material type, required approval fields for high-risk vendor changes, and similar rules. Because they run inside the CR before final activation, they act as a quality gate that is far cheaper than fixing bad data after it has already replicated to ERP, CRM, or other consuming systems. This is a foundational reason MDG project teams invest early effort in defining a validation catalog aligned with the organization's data quality objectives, rather than treating validations as an afterthought bolted on late in the project. Deployment context matters here: in S/4HANA on-premise and private cloud editions, consultants generally have direct access to configure rule assignments and build BRF+ artifacts. In public cloud editions, the extensibility model is more constrained, and validation configuration is typically done through the delivered extensibility and key-user tooling rather than unrestricted BRF+ workbench access, with SAP determining which extension points are exposed. Consultants should always verify current extensibility scope for the specific cloud release rather than assuming on-premise flexibility applies.

Code example

Illustrative BRF+ decision-table logic (conceptual, not a literal API): Rule: 'Vendor_Country_TaxNumber_Check'Entity: Business Partner (Vendor role)Trigger step: Create and Change Condition table (conceptual):Country = 'DE' AND TaxNumberType = blank -> Message: 'Tax number type is required for German vendors' (Severity: Error)Country = 'DE' AND VATRegNo = blank -> Message: 'VAT registration number recommended for German vendors' (Severity: Warning) Processing note: this logic assumes any derivation that defaults TaxNumberType from a template has already executed, since validations should evaluate final, derived values rather than raw input.

Real project scenario

A retail company implementing MDG for vendor master data needed to ensure that any new vendor located in a country requiring a specific tax registration format could not be approved without that field populated. The data quality lead defined a validation rule scoped to the vendor create process, evaluated at the point where the requester submits the change request for review. Initially the rule was written to check the raw input field before a related derivation rule populated a default classification, causing valid vendors to be incorrectly flagged as errors. The project team resolved this by confirming the rule execution order in the data model configuration and adjusting the validation to run after derivations, then retested with representative country-specific test data before moving the rule to the production rule set.

Common mistakes

• Assuming validations can modify or default data; they can only evaluate and message, not set values • Writing rules that check raw input fields without accounting for derivation execution order • Using error severity for rules that should be advisory, blocking legitimate business processes unnecessarily • Failing to scope the rule to the correct entity usage (create vs change), causing it to fire in unintended steps • Not testing with representative data combinations before moving rules into the productive rule set

Best practices

• Maintain a documented validation catalog mapping each rule to the business policy it enforces • Confirm execution order relative to derivations before assuming a validation will see final values • Use warning severity for advisory guidance and reserve error severity for true policy blockers • Scope rules to the correct create/change usage to avoid unnecessary reprocessing • Test each rule against both compliant and non-compliant sample data before promoting to production

Interview angle

Interviewers often probe whether a candidate understands the functional difference between validations and derivations, and whether they know that severity level controls workflow blocking behavior. A strong answer explains that validations evaluate rather than modify data, that error severity halts CR progression at the step where it fires, and that execution order relative to derivations is a common source of defects that experienced consultants explicitly test for.