Designing Decision Tables and Rules for MDG Derivations and Validations
Learn how to design, test, and integrate BRFplus decision tables and validation expressions that drive field derivation and data quality checks inside MDG change requests.
Explanation
Once a consultant understands BRFplus fundamentals, the next skill is actually designing rule artifacts that behave predictably inside a live MDG change request. The most common pattern for derivations is the decision table: a tabular structure where each row maps a combination of condition columns (input values, such as company code, account group, or region) to one or more result columns (the derived output, such as a G/L account or a default currency). Decision tables are attractive because business analysts can read and maintain them almost like a spreadsheet, and they compile into efficient lookups at runtime rather than long chains of nested IF logic. Designing a decision table well requires discipline. First, define condition columns using the smallest reasonable input set — every additional condition column multiplies the number of rows needed to cover all real combinations, and sparse coverage causes derivations to silently fail (return blank) for combinations nobody anticipated. Second, use column-level default or wildcard handling deliberately where the framework supports it, rather than trying to enumerate every combination, and document which rows are catch-all fallbacks. Third, keep result columns typed consistently with the target MDG field's domain (length, data element, value help) to avoid runtime type mismatches or truncation. For validations, the pattern differs slightly: instead of producing a derived value, the BRFplus function's logic evaluates conditions and returns a message (or a message with severity — error, warning, information) that the MDG change request framework then attaches to the specific field or entity being validated. A well-designed validation rule should reference only the fields actually needed for the check, return a message text that is specific enough for the requester to know how to correct the issue, and — critically — be scoped to the correct processing step. A validation that should only fire at final approval should not also fire during initial draft creation, or requesters will be blocked from saving incomplete-but-in-progress drafts. Testing is where many implementations fall short. BRFplus provides a simulation capability within the workbench that lets you execute a function with sample input values and inspect the output before it is ever wired into an MDG change request — this should always be the first testing step, isolating rule logic defects from MDG integration or workflow defects. Only after simulation confirms correct behavior should testing move to an actual change request in a test client, because change-request-level testing conflates rule logic, entity type configuration, and workflow step configuration, making root-cause analysis slower. Integration and troubleshooting considerations: when a derivation appears not to fire at all, check first whether the business rule event is even configured to call the expected function for that entity type and usage — a missing or incorrect mapping is more common than a defective rule. When a derivation fires but returns unexpected results, use simulation with the exact input values from the problematic record to reproduce the issue outside the change request. When a validation blocks a change request unexpectedly, check the processing step scoping and confirm the rule was not recently modified without corresponding regression testing of previously passing records. Across deployments, be aware that S/4HANA on-premise and private cloud MDG implementations typically retain the classic BRFplus workbench experience, while some newer, more consolidated or cloud-ready governance scenarios may surface rule configuration through different, more guided tooling; consultants should confirm current tooling and integration touchpoints for the specific release rather than assuming the workbench-centric approach is universal.
Real project scenario
During UAT for a material master governance project, testers report that a unit-of-measure derivation works correctly for domestic plants but returns blank for two newly added international plants. The consultant opens the relevant BRFplus function in simulation mode, enters the failing plant codes as input, and confirms the decision table simply has no row covering those plants' region code — a straightforward data gap fixed by adding the missing rows and re-running simulation before retesting in the change request.
Common mistakes
• Building decision tables with too many condition columns, creating unmanageable row counts and frequent derivation gaps • Skipping BRFplus-level simulation and debugging rule defects only inside full change request testing, which slows root-cause analysis • Scoping validation rules to fire on every processing step instead of the specific step where the check is meaningful, blocking legitimate draft saves • Returning vague validation message text that does not tell the requester which field or value caused the failure • Assuming a derivation defect is a BRFplus bug when the actual cause is a missing or misconfigured business rule event mapping in MDG
Best practices
• Design decision tables with minimal, well-chosen condition columns and explicit documented fallback rows • Always run BRFplus simulation with real problem-record input before assuming a change request-level defect • Scope validations precisely to the processing step where the check is meaningful to avoid blocking legitimate in-progress drafts • Write validation messages specific enough that requesters can self-correct without escalation • Maintain a test log of representative input combinations for regression testing whenever a decision table or validation rule is modified
Interview angle
Candidates are often asked to walk through a troubleshooting scenario where a derivation or validation behaves unexpectedly in a change request, and strong answers explicitly separate rule-logic testing (BRFplus simulation) from integration testing (event mapping) from process testing (workflow step scoping) rather than guessing at a single cause.