Designing, Configuring, and Troubleshooting Validation Rules in MDG

Explanation

Building validation rules that behave reliably in production requires more than writing correct business logic; it requires understanding how MDG invokes rules at runtime, how messages surface to end users, and how to diagnose failures when a rule does not fire as expected. This lesson focuses on the practical configuration and troubleshooting workflow a consultant follows when implementing validations. The typical design process starts with a business requirement expressed in plain language (for example, 'a cost center change request must not be approved if the responsible profit center is blocked'). The consultant translates this into a rule expressed against the MDG data model entity and its relevant attributes, then implements the underlying logic using BRF+ artifacts such as decision tables, expressions, or rule composition, depending on the complexity of the condition. Simple attribute comparisons are usually implemented as decision tables because they are easier for business users and auditors to review; more complex multi-attribute logic, or logic requiring lookups against other data, may require expression-based rules or function calls, and the consultant must weigh maintainability against complexity when choosing the implementation approach. After the rule logic is built, it must be assigned to the correct entity, usage, and processing step within the MDG data model configuration. This assignment step is where many defects originate: a rule built correctly in BRF+ will simply never fire if it is not properly linked to the corresponding rule type and entity in MDG configuration, or if it is assigned to the wrong processing step (for example assigned only to 'change' when the business requirement also needs it during 'create'). Consultants should always verify the assignment through configuration review, not just by reading the BRF+ artifact in isolation. Testing validation rules should happen at multiple levels. First, unit-level testing inside the BRF+ simulation environment confirms the rule logic returns the expected message and severity for a range of input combinations, including boundary and negative cases. Second, integration testing inside an actual change request confirms the rule fires at the correct step, that the message text and severity display correctly to the end user, and that the CR is blocked or allowed to progress as intended. Third, regression testing after any data model or derivation change is important, since validations often depend on values populated by other rules earlier in the processing sequence; a change elsewhere in the rule chain can silently break a validation that was previously working. When a validation does not behave as expected in production, the troubleshooting approach generally follows a structured path: confirm the rule is active and correctly assigned to the entity/usage/step; confirm the attribute values present in the change request at the time of evaluation, since values may differ from what the requester typed if a derivation adjusted them; check whether the rule condition logic actually matches the real-world data pattern being tested, since condition tables with overlapping or missing rows are a frequent source of rules that fire inconsistently; and review whether multiple validations are interacting, since a rule that appears not to have fired may actually have fired but its message was suppressed or superseded by workflow logic showing only the highest-severity outcome to the user in certain UI configurations. Performance is a secondary but real concern, particularly for validations that perform lookups against other MDG entities, external systems, or large decision tables evaluated frequently during interactive editing. Rules that call out to remote checks or complex nested logic during every field change can noticeably slow down the change request UI, so consultants should be deliberate about which validations run on every field change versus only at defined checkpoints such as request submission. Across deployment types, the mechanics of rule evaluation are conceptually similar, but the tooling access differs: on-premise and private cloud implementations generally allow direct BRF+ workbench access for building and testing rules, while public cloud implementations rely on delivered extensibility tooling with a more limited surface area, and some complex custom logic patterns available on-premise may not have an equivalent in the cloud extensibility model. Consultants working across deployment types should validate what customization is actually supported for the specific release before committing a design to a project plan.

Code example

Conceptual troubleshooting checklist expressed as pseudo-steps (not literal system commands): 1. Confirm rule status = active in the relevant BRF+ application2. Confirm rule type assignment in MDG data model configuration matches entity + usage + processing step3. Reproduce the change request scenario and inspect field values at the moment of validation execution4. Simulate the rule directly in the BRF+ test environment using the exact captured field values5. If simulation passes but the CR does not show the expected message, review UI message filtering/severity display settings6. If simulation fails, review decision table rows for gaps or overlapping conditions

Real project scenario

During a materials governance rollout, business users reported that a validation intended to block creation of a material with an invalid unit-of-measure combination was not firing for certain plants. Investigation showed the rule was correctly built and tested in isolation in BRF+, but had only been assigned to the 'create' processing step in the data model configuration, while the problematic scenario occurred during a 'change' transaction that added the plant-specific data later. The team corrected the assignment to include both create and change usages, retested with the original failing scenario, and added a regression test case to the project's validation test suite to prevent recurrence.

Common mistakes

• Building correct BRF+ logic but failing to verify its assignment to the right entity, usage, and processing step • Testing only in the BRF+ simulation tool without confirming behavior inside an actual change request • Overlooking that a derivation or another validation altered field values before the rule under test executed • Creating decision tables with gaps or overlapping rows that produce inconsistent firing behavior • Adding expensive lookup-based validations that fire on every field change and degrade UI responsiveness

Best practices

• Always confirm rule assignment to entity, usage, and processing step in configuration, not just BRF+ logic correctness • Build a layered test suite covering BRF+ simulation, in-context CR testing, and regression testing after related changes • Reserve expensive lookup-based validations for checkpoint steps rather than every field change • Document known rule execution order dependencies so future changes do not silently break existing validations • Verify extensibility and tooling access available for the specific deployment (on-premise, private cloud, public cloud) before finalizing design

Interview angle

Candidates are often asked how they would troubleshoot a validation that appears not to fire. A strong answer walks through checking rule activation, data model assignment to the correct entity/usage/step, actual field values at evaluation time, and BRF+ simulation with captured data, rather than assuming the rule logic itself is wrong first.