Configuring and Troubleshooting Derivation Rules: Runtime Flow and Diagnostics

Explanation

Once the business need for a derivation is clear, an MDG configuration specialist implements it by linking a BRF+ application (or the relevant rule artifact in the applicable release) to the specific business activity and entity type in the governance configuration, so that the framework knows when to call the rule during change request processing. The typical configuration steps are: define or confirm the entity type and attribute in the data model that will receive the derived value, build the BRF+ decision table or rule expression with the correct context (the input attributes MDG passes in, such as country, entity type, classification), map the rule's output back to the target field, and assign this rule to the correct processing step, commonly a step tied to entity validation and derivation configuration for that business object and business activity (create, change, or both). Runtime flow matters because timing determines what data is available when the rule fires. Typically, derivation rules execute after the user has entered or changed data in the UI, at a defined checkpoint before the change request advances, and potentially again at later workflow steps if configured to re-run. This means a rule that depends on an attribute filled in a later UI step may not yet have that attribute available if it runs too early, producing an empty or default fallback value. Conversely, if a derivation runs multiple times across the change request lifecycle without idempotent logic, it can unexpectedly overwrite a value that a downstream approver manually corrected. Understanding this execution sequence is critical to avoid designing rules that behave inconsistently depending on which workflow step a steward is in when they trigger a save or check action. Integration considerations: derived values become part of the active area of the change request and later part of the master record once the change request completes, so any distribution or replication happening afterward will carry the derived value, not the original entered value. If a consuming system such as an ERP backend expects a specific value and the derivation logic is wrong, the error will typically surface downstream as a replication failure or a follow-on validation failure in the target system rather than immediately in MDG, making root-cause tracing harder unless proper logging is in place. Troubleshooting a misbehaving derivation typically starts by reproducing the exact input combination that produced the wrong output and testing the BRF+ rule in isolation using its own trace/simulation capability, if available in the release, to confirm whether the rule itself is correct or whether the issue is in how MDG passes context data into the rule. Common root causes include: incorrect or stale context mapping (the field the rule expects doesn't match the field MDG actually sends), missing rows in a decision table for a newly introduced value (for example a new country or new classification code that was never added to the table), and rule assignment to the wrong business activity or entity type so the rule silently never fires for certain create/change scenarios. Application or governance-level logs available for the change request, together with a controlled test change request, are the most reliable way to confirm at which processing step the derivation was expected to run and whether it actually executed. A further nuance for intermediate practitioners: because business rules evolve, decision tables need a maintenance process, ideally with business ownership of the table content and IT ownership of the rule structure, so that adding a new valid combination (say, a new region code) does not require a full development cycle each time, only a controlled content change with appropriate testing and transport.

Code example

Example BRF+-style decision table logic for a business partner payment terms derivation (illustrative, not literal syntax): Condition columns: Country | Customer Classification | Sales OrgResult column: Payment Terms Row 1: DE | Retail | 1000 -> ZB01Row 2: DE | Wholesale | 1000 -> ZB02Row 3: FR | Retail | 2000 -> ZF01Row 4: * (any) | * (any) | * (any) -> ZDEFAULT (fallback row, always last) Key configuration points to verify during setup:1. Confirm the rule is assigned to entity type BP (or relevant entity) for business activity CREATE and CHANGE if defaulting should apply to both.2. Confirm context mapping: Country field in BRF+ must map to the same source attribute MDG populates from the UI/data model, not a similarly named but different field.3. Always include a fallback/default row so missing combinations do not return a blank value.4. Test with a representative change request for each row plus one deliberately unmatched combination to confirm fallback behavior.

Real project scenario

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.

Common mistakes

• Omitting a fallback/default row in decision tables, causing blank or null results for any combination not explicitly listed. • Assuming a derivation rule fires at the same processing step for both create and change activities without verifying activity-specific assignment. • Mapping the wrong source attribute into the rule context, so the rule technically runs but always evaluates against incorrect input. • Not testing what happens when a derivation runs more than once across workflow steps, risking silent overwrite of a manually corrected value. • Relying solely on end-user reports to diagnose issues instead of reproducing the exact input combination in a controlled test change request.

Best practices

• Always include an explicit fallback/default outcome in decision tables to avoid blank derived values. • Verify and document which business activities (create, change, or both) and which workflow step a derivation rule is tied to. • 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. • Log or trace derivation execution during testing so that downstream replication failures can be traced back to a specific rule and input combination.

Interview angle

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.