Advanced Derivations: Architecture, Integration and Production Design (Part 4)

At senior and architect level, Derivations should be understood as an end-to-end design problem rather than a list of isolated features.

Core design map
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.

Configuring and Troubleshooting Derivation Rules: Runtime Flow and Diagnostics: Learn how derivation rules are configured using the MDG rule framework and BRF+, how they execute during the change request lifecycle, and how to troubleshoot when derived values are wrong, missing, or inconsistent.

Configuring and Troubleshooting Derivation Rules with BRFplus in MDG: Learn how derivation rules are built using BRFplus (or the rules engine available in your MDG release), wired into the data model and UI, executed at runtime, and diagnosed when values fail to populate as expected.

Architecture and production criteria

• Always include a default/catch-all row or fallback logic in decision tables to avoid silent blank results
• Always include an explicit fallback/default outcome in decision tables to avoid blank derived values.
• Capture all known business exceptions up front so the rule table design anticipates them rather than requiring rework.
• 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.
• Confirm what extensibility technique (BRFplus vs. cloud-specific tools) is actually available before committing to custom derivation logic in a given deployment
• Document precedence rules: does a derived value override manual entry, or only fill blanks.
• Document the sequence of derivation and validation steps for each Business Activity so dependencies are explicit
• Involve business process owners in reviewing the decision table logic in plain language before configuration is finalized.
• Keep derivation logic in BRFplus rather than hardcoding it in UI configuration or custom code, to preserve traceability and reusability
• Log or trace derivation execution during testing so that downstream replication failures can be traced back to a specific rule and input combination.
• Maintain a test matrix covering every meaningful attribute combination plus at least one unmatched case per rule.
• Separate business-owned rule content maintenance from IT-owned rule structure changes, with a lightweight change process for adding new valid values.
• Test derivation rules against real historical master data combinations, not just synthetic test cases, before promoting to production
• Use BRFplus simulation and trace tools to validate context data before assuming a rule is broken
• Verify and document which business activities (create, change, or both) and which workflow step a derivation rule is tied to.

Failure analysis and operational risk

• Assuming a derivation is active without checking the Business Activity/entity type/change request type scope, when in fact it was restricted to a different combination
• Assuming a derivation rule fires at the same processing step for both create and change activities without verifying activity-specific assignment.
• Assuming any field on the UI can host a derivation without confirming the field is part of the governed data model for that object.
• Assuming the same BRFplus workbench access and custom rule-building capability exists in every deployment, including public cloud tenants with restricted extensibility
• Building decision tables without a default or catch-all row, so unmatched input combinations silently leave fields blank
• Confusing a derivation requirement with a validation requirement during requirements gathering, leading to rules being built with the wrong intent.
• Mapping BRFplus context fields to source fields that are not yet populated at the point the derivation step executes, due to incorrect step sequencing
• Mapping the wrong source attribute into the rule context, so the rule technically runs but always evaluates against incorrect input.
• Not documenting the precedence between a manually entered value and a derived value, causing confusion when stewards see their entry silently overwritten.
• Not testing derivation logic against edge-case or newly introduced master data combinations before go-live
• Not testing what happens when a derivation runs more than once across workflow steps, risking silent overwrite of a manually corrected value.
• Omitting a fallback/default row in decision tables, causing blank or null results for any combination not explicitly listed.
• Placing a validation step before the derivation step that is supposed to populate the field the validation checks, causing false validation failures
• Relying solely on end-user reports to diagnose issues instead of reproducing the exact input combination in a controlled test change request.
• Treating derivation logic as a one-time build with no plan for ongoing business rule changes as company policy evolves.
• Underestimating how many exception cases exist (regional variants, special customer types) and building an overly simple single-rule derivation that fails for edge cases.

A strong production design connects functional or analytical semantics to integration boundaries, security, performance, transport/change control, observability, recovery and ownership. Trade-offs should be justified with evidence such as volume, latency, data quality, user behavior, operational SLA and downstream dependencies. Avoid treating a technically successful configuration or interface as complete until the business result is reconciled end to end.

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.

During UAT for an MDG material governance rollout, testers report that valuation class is derived correctly for materials created in the base plant but comes back blank for a newly onboarded plant. Investigation shows the decision table only had rows for the original three plants; the new plant combination fell through to a rule with no fallback row. The team adds a fallback default and a proper row for the new plant, then re-tests the create and change scenarios, and adds the missing combination to the change control checklist for future plant onboarding.

A global chemicals company governs material master records in MDG and wants to auto-derive the default storage condition and hazardous material indicator based on material group and country of production, so plant data stewards do not have to look up this mapping manually. The team builds a BRFplus decision table keyed by material group and plant country, attaches it as a derivation step to the Change Material Business Activity, and sequences it to run immediately after the entity type step where material group is entered but before the hazardous substance validation step runs. During UAT, testers report that new materials in a newly added country show blank hazardous indicators; tracing the BRFplus function reveals the decision table has no row for that country, so the team adds a fallback/default row plus a data steward review workflow step for combinations not covered by the table.

• Assuming a derivation is active without checking the Business Activity/entity type/change request type scope, when in fact it was restricted to a different combination
• Assuming a derivation rule fires at the same processing step for both create and change activities without verifying activity-specific assignment.
• Assuming any field on the UI can host a derivation without confirming the field is part of the governed data model for that object.
• Assuming the same BRFplus workbench access and custom rule-building capability exists in every deployment, including public cloud tenants with restricted extensibility
• Building decision tables without a default or catch-all row, so unmatched input combinations silently leave fields blank
• Confusing a derivation requirement with a validation requirement during requirements gathering, leading to rules being built with the wrong intent.
• Mapping BRFplus context fields to source fields that are not yet populated at the point the derivation step executes, due to incorrect step sequencing
• Mapping the wrong source attribute into the rule context, so the rule technically runs but always evaluates against incorrect input.
• Not documenting the precedence between a manually entered value and a derived value, causing confusion when stewards see their entry silently overwritten.
• Not testing derivation logic against edge-case or newly introduced master data combinations before go-live
• Not testing what happens when a derivation runs more than once across workflow steps, risking silent overwrite of a manually corrected value.
• Omitting a fallback/default row in decision tables, causing blank or null results for any combination not explicitly listed.
• Placing a validation step before the derivation step that is supposed to populate the field the validation checks, causing false validation failures
• Relying solely on end-user reports to diagnose issues instead of reproducing the exact input combination in a controlled test change request.
• Treating derivation logic as a one-time build with no plan for ongoing business rule changes as company policy evolves.
• Underestimating how many exception cases exist (regional variants, special customer types) and building an overly simple single-rule derivation that fails for edge cases.

• Always include a default/catch-all row or fallback logic in decision tables to avoid silent blank results
• Always include an explicit fallback/default outcome in decision tables to avoid blank derived values.
• Capture all known business exceptions up front so the rule table design anticipates them rather than requiring rework.
• 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.
• Confirm what extensibility technique (BRFplus vs. cloud-specific tools) is actually available before committing to custom derivation logic in a given deployment
• Document precedence rules: does a derived value override manual entry, or only fill blanks.
• Document the sequence of derivation and validation steps for each Business Activity so dependencies are explicit
• Involve business process owners in reviewing the decision table logic in plain language before configuration is finalized.
• Keep derivation logic in BRFplus rather than hardcoding it in UI configuration or custom code, to preserve traceability and reusability
• Log or trace derivation execution during testing so that downstream replication failures can be traced back to a specific rule and input combination.
• Maintain a test matrix covering every meaningful attribute combination plus at least one unmatched case per rule.
• Separate business-owned rule content maintenance from IT-owned rule structure changes, with a lightweight change process for adding new valid values.
• Test derivation rules against real historical master data combinations, not just synthetic test cases, before promoting to production
• Use BRFplus simulation and trace tools to validate context data before assuming a rule is broken
• Verify and document which business activities (create, change, or both) and which workflow step a derivation rule is tied to.

Senior interviews should test whether the candidate can connect the individual lesson areas, diagnose cross-layer failures, explain trade-offs and design a supportable production operating model.

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.

Interviewers assess whether a candidate can explain the practical runtime sequence of derivations within the change request lifecycle and describe a structured troubleshooting approach (isolate the rule, verify context mapping, check business activity assignment, confirm fallback logic) rather than guessing at fixes. Be ready to walk through a real defect you diagnosed step by step.

Interviewers often probe whether a candidate understands that MDG derivations are typically implemented via BRFplus rather than being a separate proprietary engine, and whether the candidate can explain the difference between a derivation (auto-populating a value) and a validation (checking a value). Be ready to discuss how you would diagnose a derivation that isn't firing (checking activity/entity scope, context mapping, and BRFplus trace) and how step sequencing between derivations and validations affects outcomes. Architect-level interviews may ask how derivation logic differs between on-premise and cloud deployments in terms of who can modify rules and how.