Why Derivations Matter and Where They Fit in MDG Data Governance
Understand what a derivation is in SAP MDG, why organizations use it, and how it fits into the broader governance process alongside validations and workflow.
Explanation
In SAP Master Data Governance, a derivation is logic that automatically fills in or overwrites a field value on a master data object based on other data already present, rather than requiring a data steward to type it manually. For example, when a data steward creates a new material, the material group might automatically derive the default valuation class, or when a business partner is created with a certain country and industry, the account group or reconciliation account could be derived. The core business purpose is threefold: reduce manual data entry effort, reduce human error in fields that follow predictable rules, and enforce enterprise-wide standards that would otherwise depend on every steward remembering a policy. Derivations are conceptually different from validations. A validation checks whether a value entered by a user is acceptable and blocks or warns if not. A derivation actively sets or changes a value without necessarily requiring the user to enter anything, or it overrides what was entered based on business rules. Both derivations and validations typically sit in the same rule framework layer within MDG, evaluated during specific steps of the change request lifecycle, such as after data entry and before or during workflow processing, or at the point a change request moves to a particular workflow step. In SAP MDG on S/4HANA, the primary vehicle for building derivation logic is the Business Rule Framework plus (BRF+), which lets configuration experts and semi-technical business analysts build decision tables, rule sets, and expressions without writing full ABAP classes for every scenario. A decision table might say: if country = DE and material type = ROH, then set valuation class = 3000. Multiple such rows can be combined into a single rule that MDG calls at the appropriate point in processing. Behind BRF+, MDG provides an integration layer that maps entity attributes into BRF+ context data and pushes derived results back into the active data governance model for that change request. Why this matters for a beginner-level consultant is that derivations are one of the most frequently requested customizations in an MDG implementation. Business stakeholders often start a project by describing manual Excel-based defaulting rules they want automated. Recognizing that this is a derivation (not a validation, not a workflow step) and understanding roughly how it will be built helps a functional consultant scope requirements correctly, ask the right questions (what is the trigger field, what is the derived field, are there exceptions), and communicate realistic expectations about maintenance effort. Because BRF+ rules are typically maintained by a configuration team rather than developers, many derivation changes can be handled without an ABAP transport-heavy cycle, which is an important selling point during governance design workshops, though it still normally requires transport of the BRF+ application object as part of standard change management. A final foundational point: derivations execute within the entity and attribute model defined for governance (the data model that MDG maintains), so a consultant must know which fields are governed by MDG for a given object (material, business partner, or a custom object) before assuming a derivation can be attached to it. Fields that are not part of the governed data model, or that are only replicated but not maintained through MDG UIs, are not typically candidates for MDG-side derivation.
Real project scenario
A retail company implementing MDG for business partner governance wants every new customer created in Germany to automatically receive a default payment terms code and a default dunning procedure based on customer classification, instead of relying on data stewards to remember regional finance policy. The functional consultant documents this as a derivation requirement, clarifies with the finance team which attribute combinations drive the default (country, customer classification, sales organization), and hands this off to the rules configuration team to build as a BRF+-based derivation rather than a validation, since the values must be set automatically, not just checked.
Common mistakes
• Confusing a derivation requirement with a validation requirement during requirements gathering, leading to rules being built with the wrong intent. • Assuming any field on the UI can host a derivation without confirming the field is part of the governed data model for that object. • Underestimating how many exception cases exist (regional variants, special customer types) and building an overly simple single-rule derivation that fails for edge cases. • Not documenting the precedence between a manually entered value and a derived value, causing confusion when stewards see their entry silently overwritten. • Treating derivation logic as a one-time build with no plan for ongoing business rule changes as company policy evolves.
Best practices
• Clearly separate derivation requirements from validation requirements during design workshops using simple business language (auto-fill vs. check-and-block). • Confirm the target field is part of the active governed data model before committing to a derivation design. • Document precedence rules: does a derived value override manual entry, or only fill blanks. • Capture all known business exceptions up front so the rule table design anticipates them rather than requiring rework. • Involve business process owners in reviewing the decision table logic in plain language before configuration is finalized.
Interview angle
Interviewers commonly probe whether a candidate can distinguish derivations from validations and explain where each fits in the MDG rule framework, plus whether the candidate understands that BRF+ is the typical configuration vehicle in S/4HANA MDG. Be ready to describe a real derivation example you scoped or tested, including the trigger fields and the business reason.