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.
Explanation
Derivations exist to remove manual, error-prone data entry by letting the system infer field values from other known data. In MDG, the most common implementation vehicle is BRFplus (Business Rule Framework plus), which is invoked through a derivation step attached to a Business Activity or entity type in the governance configuration. Some MDG releases and domains expose simplified rule configuration through Customizing activities that internally generate or reference BRFplus functions, so the underlying mechanism is often BRFplus even when the entry point looks like a table-based Customizing screen. The design starts with identifying the trigger point: derivations can fire on initial creation of a change request, on saving a step, before validation, or when a specific field changes (for example, deriving a reconciliation account when a G/L account's account group and chart of accounts are set, or deriving a language-independent search term when a description is entered). You configure the derivation step against a Business Activity and Entity Type combination, specify the BRFplus application and function ID to call, and map the context data (the fields from the entity that BRFplus needs as input) to the BRFplus data object model. Inside BRFplus, you build a Decision Table, Formula, or Rule Flow that reads the input context and returns one or more derived values, which the framework then writes back to the corresponding fields on the governed entity. At runtime, when a user progresses a change request or the workflow step is processed, the framework resolves the sequence of active derivation steps for that Business Activity, builds the context object from current entity data, and calls into BRFplus. BRFplus evaluates the top-level rule (often a decision table ordered by priority or a ruleset with conditions) and returns a result, which is written to the UI or persisted to the staging area of the change request. Because this happens before the entity is saved or before validations run, you can build layered logic: first derive values, then validate the resulting record. Common configuration constructs include decision tables keyed by combinations of master data attributes (e.g., country plus material type derives a default valuation class), formulas for concatenation or numeric calculations (e.g., building a search term from multiple fields), and expressions that call custom function modules for logic too complex for a decision table. Multiple derivation steps can be sequenced, and later steps can depend on results from earlier ones, so step order matters and should be documented. Troubleshooting derivations usually starts with confirming whether the derivation step is even active for the relevant Business Activity, entity type, and change request type combination, since scope restrictions are a frequent cause of unexpected non-execution. Next, check the BRFplus function trace (BRFplus provides simulation and trace tools) to verify the context values passed in are what you expect; a very common failure mode is that the context field mapping references a field that is blank at the time the derivation fires because the user has not yet entered it, or because it comes from a different processing step. Another frequent issue is decision table gaps: if no row matches the input combination, BRFplus returns no result, which can silently leave a field blank unless a default/catch-all row is defined. Order-of-execution problems occur when a later validation runs before a derivation step that was supposed to populate a mandatory field. Across deployments, on-premise and private cloud systems typically allow direct BRFplus workbench access, so consultants can build and adjust decision tables and simulate them with sample data. In public cloud, direct BRFplus development access is generally restricted, and derivation logic is more likely delivered as fixed rules or exposed only through supported cloud configuration/extensibility tools; consultants should not assume the same workbench access exists and should validate what extension technique is available in that tenant before promising custom derivation logic. Governance teams should treat derivation rules as any other configuration transport: they must be tested in a non-production client with representative master data combinations, and simulation/trace tools should be used before go-live to catch missing decision table rows.
Real project scenario
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.
Common mistakes
ā¢ 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 ā¢ Building decision tables without a default or catch-all row, so unmatched input combinations silently leave fields blank ā¢ Mapping BRFplus context fields to source fields that are not yet populated at the point the derivation step executes, due to incorrect step sequencing ā¢ Placing a validation step before the derivation step that is supposed to populate the field the validation checks, causing false validation failures ā¢ Assuming the same BRFplus workbench access and custom rule-building capability exists in every deployment, including public cloud tenants with restricted extensibility ā¢ Not testing derivation logic against edge-case or newly introduced master data combinations before go-live
Best practices
ā¢ Document the sequence of derivation and validation steps for each Business Activity so dependencies are explicit ā¢ Always include a default/catch-all row or fallback logic in decision tables to avoid silent blank results ā¢ Use BRFplus simulation and trace tools to validate context data before assuming a rule is broken ā¢ Keep derivation logic in BRFplus rather than hardcoding it in UI configuration or custom code, to preserve traceability and reusability ā¢ Test derivation rules against real historical master data combinations, not just synthetic test cases, before promoting to production ā¢ Confirm what extensibility technique (BRFplus vs. cloud-specific tools) is actually available before committing to custom derivation logic in a given deployment
Interview angle
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.