When working with SAP Master Data Governance (MDG), it’s common to face situations where a field behaves differently than expected — maybe it’s hidden for one user role but visible for another, or a layout change doesn’t appear. These issues often come down to how different UI layers interact with each other.
To make sense of it, let’s walk through how SAP MDG decides which configuration takes effect when you use standard setup, CBA, customization, and enhancements.
Standard Configuration – The Starting Point
Every MDG screen begins with the standard SAP configuration. This includes the delivered Floorplan Manager (FPM) setup, feeder classes, and event logic. Think of this as the foundation. Everything else — from customizations to enhancements — builds on top of it.
Context-Based Adaptation (CBA)
CBA allows you to adapt the UI depending on the context — such as a business role, change request type, or entity type. If more than one CBA applies, the system picks the one with the highest priority (defined by the lowest numeric value in customizing). CBA runs before any runtime logic and overrides the standard configuration. It’s the best option when you want different screens or layouts for different user roles or processes.
UI Customization
Once the relevant configuration (standard or CBA) is loaded, the system applies any UI customizations you’ve made. These are the changes you do in the FPM configuration editor — for example, hiding a field, changing labels, or adjusting layout groups. If both a CBA and a customization touch the same field, the CBA takes priority because it decides which version of the configuration is active.
UI Enhancements
After all the configuration-based layers are applied, enhancements come into play. These are ABAP-based runtime changes done through custom logic or BadIs. Enhancements have the highest priority because they run at runtime and can override anything set in configuration or CBA. For example, even if a field is hidden in CBA, an enhancement can make it visible again based on business rules.
Summary of Priority
Priority| Layer| What It Does
Best Practice:
Understanding this order helps avoid conflicts between configurations and ensures your MDG UI behaves consistently. It also makes your design easier to maintain and extend as your governance processes evolve.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
| User | Count |
|---|---|
| 12 | |
| 5 | |
| 5 | |
| 5 | |
| 4 | |
| 4 | |
| 3 | |
| 3 | |
| 3 | |
| 3 |