B.   The next workflow step

C.   Possible actions in the user interface

D.   The next change request status

Explanation:

In the SAP MDG Rule-Based Workflow (RBW), the combination of the Change Request (CR) Status and the Workflow Step acts as the primary key for the decision-making engine within the BRF+ environment.

B. The next workflow step:
The decision table DT_SINGLE_VAL_SET_RET uses the current status and step to determine the "Condition Alias." This alias then points to the next logical step in the process (e.g., moving from "Submission" to "Approval").

C. Possible actions in the user interface:
The workflow step is linked to the User Task configuration. By evaluating the current step, the system determines which buttons (like Approve, Reject, or Finalize) are visible to the user in the MDG Communicator.

D. The next change request status:
One of the core outputs of the BRF+ mapping is the New CR Status. Based on the action taken (e.g., Action 01 - Approve), the status is updated (e.g., from "In Process" to "Changes to be Executed").

Why the other options are incorrect:

A. Predecessor steps in the workflow:
The RBW logic is forward-looking. The system evaluates the current state to determine the next state. While logs show history, the process logic itself does not "determine" previous steps; it only reacts to the current one.

E. User responsible for the next workflow step:
This is a common trap. The User is determined by the Agent Selection rules (via the DT_USER_AGT_GRP_XXX table), not directly by the process logic that defines the status and step transitions. The process logic determines what happens next, while agent rules determine who does it.

References:
SAP Help Portal: Master Data Governance > Configuration of Master Data Governance > Process Modeling > Workflow > Rule-Based Workflow.

B.   SAP MDG, Finance can govern and distribute master data to the Central Finance system.

D.   SAP MDG consolidation supports the cleansing and loading of financial master data objects.

Explanation:

B. SAP MDG, Finance can govern and distribute master data to the Central Finance system ✅
- This is a core integration capability where MDG-Finance acts as the central governance hub. It creates, maintains, and distributes harmonized financial master data (such as general ledger accounts, cost centers, and profit centers) to the Central Finance system, ensuring consistency across the landscape . The Data Replication Framework (DRF) enables this outbound distribution to target systems like Central Finance .

D. SAP MDG consolidation supports the cleansing and loading of financial master data objects ✅
- Before Central Finance can process transactions, financial master data from multiple source systems must be harmonized. MDG consolidation provides the functionality to load, standardize, match, and cleanse this master data, creating "best records" that can then be used in Central Finance . This is essential for both initial data migration and ongoing harmonization efforts when integrating new source systems .

Why the Other Options Are Not Correct

A. Data replication can be used out of the box to send the postings to the Central Finance system ❌
- This is incorrect because postings (transactional data) are not sent from MDG to Central Finance. MDG handles master data only. Transactional postings are typically replicated from source systems to Central Finance using SAP Landscape Transformation (SLT) Replication Server, not MDG .

C. SAP MDG consolidation can create key mapping for business partner ❌
- While key mapping is absolutely critical for Central Finance integration , it is not created by the consolidation process. Key mapping is maintained through dedicated mapping functions (using transaction MDG_KM_MAINTAIN) and is associated with the central governance scenario, not the consolidation use case .

References
SAP Official Documentation on Central Finance Integration
SAP Community Blog on Key Mapping Challenges

B.   Central governance

C.   Consolidation

E.   Data quality management

Explanation:

The three basic principles of the SAP Master Data Governance (MDG) solution are Central Governance, Consolidation, and Data Quality Management .

B. Central Governance ✅
- This principle focuses on creating, changing, and distributing master data from a single, central system using defined workflows and policies. It establishes a "single source of truth" (golden record) and ensures consistency across the entire system landscape .

C. Consolidation ✅
- This principle involves merging master data from multiple source systems into a central hub to create harmonized, duplicate-free records. It is essential for initial data cleansing before implementing central governance or for harmonizing data during mergers and acquisitions .

E. Data quality management ✅
- This principle ensures the ongoing accuracy, completeness, and consistency of master data. SAP MDG provides tools to define validation rules, monitor data quality, and trigger corrective actions for any identified issues .

Why the Other Options Are Not Correct

A. Readiness for change ❌
- While SAP MDG supports business adaptation through workflows, "readiness for change" is a benefit of governance, not a core functional principle of the solution itself .

D. Organization ❌
- Although organizational structures (like company codes) are critical attributes within master data, "organization" is not a functional principle. It represents what is being managed, not how the solution functions .

References:
SAP MDG Official Product Documentation
SAP C_MDG_1909 Exam Syllabus

B.   CSV or XLSX file format to upload source records

C.   External load using business partner SOAP service

Explanation:

In SAP MDG Consolidation, the Data Load step is the initial entry point where source data is moved into the consolidation staging tables before any matching or calculation occurs.

B. CSV or XLSX file format to upload source records:
This is the standard "Local File" upload method. Users can download a template, populate it with master data (like Business Partners or Products), and upload it directly into a consolidation process. +1

C. External load using business partner SOAP service:
For automated or high-volume scenarios, MDG Consolidation supports "Inbound Services." You can push data from external systems into the consolidation framework using standard SOA (Service Oriented Architecture) messages, specifically the Business Partner SOAP services.

Why the other options are incorrect:

A. Find duplicates based on matching rules:
While this is a critical part of the consolidation process, it is not a Data Load option. Matching is a separate step that happens after the data has already been loaded into the system.

D. Validate against central governance checks:
This is also a downstream step. Validation occurs during the Validation or Activation phases of the consolidation pipeline. The "Load" phase focuses purely on technical ingestion and initial mapping of the source data, not on complex business rule validation.

Reference:
SAP Help Portal: Master Data Governance > Consolidation and Mass Processing > Loading Data.

B.   Define Quality. Enter Quality. Monitor Quality. ImproveQuality

C.   Data load. Initial check Match. Calculate best record. Validate.Activate

Explanation :

B. Define Quality. Enter Quality. Monitor Quality. Improve Quality ✅
- This is the standard process flow for Data Quality Management in SAP MDG. The cycle begins by defining quality rules based on business requirements, then ensuring quality during data entry, continuously monitoring quality through KPIs and dashboards, and finally taking improvement actions to resolve issues . This four-step approach ensures ongoing data integrity .

C. Data load. Initial check. Match. Calculate best record. Validate. Activate ✅
- This sequence accurately represents the Consolidation process flow in SAP MDG. Data is first loaded from source systems, followed by an initial check for structural validity. Matching identifies duplicates, best record calculation creates the optimal record from match groups, validation ensures data meets requirements, and activation moves the consolidated data to the active area . SAP Help Portal confirms these as the core consolidation process steps .

Why the Other Options Are Not Correct

A. Scope. Selection. Edit. Validation. Activation ❌
- This sequence does not match either consolidation or data quality management process flows. It appears to be a generic workflow that does not correspond to SAP MDG's documented processes for these specific solutions.

D. Maintain. Validate. Approve. Replicate. Adapt ❌
- This sequence describes the Central Governance process flow (change request management), not consolidation or data quality management. Central governance follows a workflow-based approach for creating and changing master data with approvals . The question specifically asks for consolidation and data quality solutions only.

References
SAP Help Portal: Process Steps for MDG Consolidation
SAP Help Portal: Master Data Governance for Customer, Consolidation

A.   FAR can be configured as successor to the validation process step to move the erroneous single records to a new duplicate process.

C.   FAR can be configured as successor to the best record calculation process step to move updated records to a new duplicate process.

E.   FAR can be configured as successor to the matching process step to move records from open match groups to a new duplicate process.

Explanation :

The Filter and Remove (FAR) adapter in SAP MDG Consolidation is a versatile tool used to split a consolidation process. It "filters" specific records out of the current process and "removes" them into a new, separate process (often referred to as a "Duplicate Process") for specialized handling.

A. FAR can be configured as successor to the validation process step...:
If the Validation step identifies records with errors that cannot be fixed immediately, the FAR step can filter these erroneous records out. This allows the "clean" data to continue toward activation while the "errors" are moved to a new process for data cleansing.

C. FAR can be configured as successor to the best record calculation...:
After the Best Record Calculation (BRC), you may have records that were updated or merged. FAR can be used to peel off these specific updated records into a separate process for a final round of review or specific governance before they are finalized.

E. FAR can be configured as successor to the matching process step...:
This is a very common use case. After Matching, if you have "Open Match Groups" (records where the system isn't 100% sure if they are duplicates), you can use FAR to move those specific groups into a new process for manual stewardship, while the "Confirmed Matches" stay in the original flow.

Why the other options are incorrect:

B. Matching process step can be configured as successor to the FAR...
to delete duplicate records: This is technically inaccurate. FAR is not used to "delete" records in the sense of a permanent purge; it is used to re-route them. Furthermore, the goal of FAR is usually to branch off from the main process, not to feed back into a Matching step to perform deletions.

D. Best Record Calculation can be configured as successor to the FAR...:
While BRC can follow FAR in a process template, the description "to move records to a new duplicate process" is the definition of what FAR does, not what BRC does. BRC calculates the "Golden Record"; it does not handle the logic of splitting processes.

Reference:
SAP Help Portal: Master Data Governance > Consolidation and Mass Processing > Process Steps > Filter and Remove.

B.   Create a custom step type and assign this as the next change request step.

C.   Adjust the rule-based workflow using the rule-context preparation BAdl.

Explanation :

When you need to introduce conditional logic into a workflow—specifically based on whether a new custom attribute is populated—you must bridge the gap between the Data Model and the Rule-Based Workflow (RBW) engine.

B. Create a custom step type and assign this as the next change request step:
In the MDG Configuration (IMG), a Step Type defines the nature of the work (e.g., "Approve Custom Data"). You must create this step so the workflow knows which UI buttons to show and which basic behavior to follow. This step is then mapped in the BRF+ decision tables as a "Next Step" when your specific conditions are met.

C. Adjust the rule-based workflow using the rule-context preparation BAdI:
This is the technical "secret sauce." By default, BRF+ sees standard Change Request header data. To make the workflow "aware" of your new custom attribute value, you must use the BAdI USMD_SSW_RULE_CONTEXT_PREPARE. This BAdI allows you to pass the value of your new attribute into the BRF+ context, enabling the decision table to "see" if the field is populated and route the flow to your new step.

Why the other options are incorrect:

A. Create a custom change request status with an additional step:
While you might update a status, a status itself does not contain an "additional step." In MDG, steps drive statuses, not the other way around. Simply creating a status does not provide the logic needed to evaluate a custom attribute.

D. Define a new business activity and a new change request type:
This is an "over-engineering" distractor. You use a new CR Type if you want an entirely different process for different users or objects. To add a single conditional step to an existing process based on a field value, you modify the workflow logic (BAdI/BRF+), not the high-level CR Type definition.

Reference:
SAP Help Portal: Configuration of Master Data Governance > Process Modeling > Workflow > Rule-Based Workflow > BAdI: Rule Context Preparation.

A.   Organization management transaction PPOME and the corresponding customizing

C.   A specific assignment of a single user or a special user (for example, previous processor or requester) in the workflow configuration

E.   A direct assignment to a specific role built in PFCG in Business Rule Framework plus

Explanation:

In SAP MDG, "Agent Selection" (determining who receives the next task) can be handled entirely through configuration and standard administrative tools, bypassing the need for custom ABAP coding.

A. Organization management transaction PPOME and the corresponding customizing:
MDG can leverage the standard SAP Organizational Management (OM) framework. By linking MDG workflow steps to Positions, Jobs, or Organizational Units defined in PPOME, the system automatically resolves which users belong to those entities at runtime.

C. A specific assignment of a single user or a special user...
in the workflow configuration: In the Rule-Based Workflow (RBW) configuration, you can use User Agent Groups. These allow you to hard-code a specific User ID or, more commonly, use system variables like "Last Processor" or "Requester" to route the change request back to the person who started or previously touched it.

E. A direct assignment to a specific role built in PFCG in Business Rule Framework plus:
This is the most common "No-Code" approach. In the BRF+ decision table DT_USER_AGT_GRP_XXX, you can enter a PFCG Role (e.g., SAP_MDGM_ROLE_APPROVER). The workflow will then automatically distribute the task to all users who have that specific role assigned to their user profile.

Why the other options are incorrect:

B. A workflow step condition that is defined in the Workflow Builder transaction SWDD:
While SWDD is the foundation of SAP Business Workflow, modifying conditions there is considered technical development/workflow design. In the context of MDG 1909, the "Rule-Based Workflow" is designed so that you stay out of SWDD and handle logic in BRF+ or IMG activities.

D. The mail configuration... using transactions SOST and SCOT:
These transactions are used for monitoring and troubleshooting the delivery of emails (e.g., checking if a notification was sent). They are purely administrative for the mail server and have no functional logic to "determine" or assign the processors of a Change Request.

Reference:
SAP Help Portal: Master Data Governance > Configuration of Master Data Governance > Process Modeling > Workflow > Rule-Based Workflow > Define User Agent Groups.

A.   Create a new business activity and use it in the change request type configuration.

D.   Configure properties of the change request step for a rule-based workflow.

Explanation:

In SAP MDG, validations are not "always on" by default for every step. They must be explicitly triggered through the configuration of the Change Request (CR) Step Properties. Depending on whether you use a standard or rule-based workflow, the configuration path differs.

C. Configure checks and enrichment spot properties for a standard business workflow:
For "Classic" workflows (non-rule-based), you define the behavior of the step in the MDG Customizing under Process Modeling > Workflow > Other Workflow > Define Change Request Step Properties. Here, you specify which Check and Enrichment spots are active for that specific step to ensure data integrity before moving to the next stage.

D. Configure properties of the change request step for a rule-based workflow:
In the Rule-Based Workflow (RBW), step properties are defined in the IMG under Process Modeling > Workflow > Rule-Based Workflow > Configure Properties of Change Request Step. This allows you to set flags such as "Validation" or "Optional" for each specific Step ID, ensuring the system executes the underlying BRF+ validations or UI-based checks when a user acts on that step.

Why the other options are incorrect:

A. Create a new business activity and use it in the change request type configuration:
A Business Activity (like MAT1 for Create Material) defines what object is being handled and which UI is used. It does not control the granular validation behavior of individual workflow steps.

B. Enable edition for the required entity type in the data model:
This is a Data Modeling task. While you must enable an entity for "Edition" to govern it within a Change Request, this setting controls whether the data can be changed, not how or when the validations are triggered during the workflow process.

Reference:
SAP Help Portal: Master Data Governance > Configuration of Master Data Governance > Process Modeling > Workflow > Define Change Request Step Properties.

A.   Run the semi-automatic workflow setup using transactionSWU3.

C.   Check the default workflow batch user (SAP_WFRT orWF_BATCH).

Explanation:

A. Run the semi-automatic workflow setup using transaction SWU3 ✅
- This is the primary tool for initial workflow setup and troubleshooting. Transaction SWU3 (Automatic Workflow Customizing) performs essential configuration checks and can identify missing or incorrect workflow settings. It should be the first step when investigating workflow issues, as it validates the complete workflow environment including RFC destinations, event linkages, and background job scheduling .

C. Check the default workflow batch user (SAP_WFRT or WF-BATCH) ✅
- The workflow system user is critical for background processing. These dedicated users (SAP_WFRT in newer S/4HANA systems or WF-BATCH in classic systems) execute workflow steps automatically. If this user has incorrect authorizations, is locked, or is missing, workflows will fail to process properly . Checking this user's status and authorizations is a standard troubleshooting step .

Why the Other Options Are Not Correct

B. Run the relevant business configuration set using transaction SCPR20 ❌
- Transaction SCPR20 is used for managing Business Configuration Sets, not for workflow troubleshooting. This transaction is unrelated to workflow engine diagnostics and would not help identify why the workflow engine is not running properly.

D. Switch on the workflow engine business function in SWF5 ❌
- Transaction SWF5 is not a valid transaction for workflow configuration. Business functions are activated using transaction SFW5 , not SWF5. This appears to be a distractor with an incorrect transaction code.

References
SAP Help Portal: Set Up Workflow
SAP Knowledge Base Article 1574002 - WF-BATCH and SAP_WFRT Authorizations
SAP MDG Configuration Guides

B.   Assign your application configuration to data model.

D.   Create a deep copy of the application configuration template.

E.   Generate implementation classes (BAdI) based on the custom data model.

Explanation:

Creating a User Interface (UI) for a custom data model in SAP MDG relies on the Floorplan Manager (FPM) framework and the GenIL (Generic Interaction Layer) to bridge the data model with the web-based screens.

B. Assign your application configuration to data model:
Once you have created your UI configurations, you must link them to the specific Data Model and Main Entity in the MDG Customizing. This ensures that when a Change Request is opened for that model, the system knows exactly which FPM application and configuration to launch.

D. Create a deep copy of the application configuration template:
SAP provides standard "Template" configurations (like USMD_ENTITY_VALUE2_PROXY). Instead of building a UI from scratch, you perform a Deep Copy of these templates. This creates the necessary Application Configuration, Component Configurations (Header and Form/List), and the required wiring.

E. Generate implementation classes (BAdI) based on the custom data model:
For the UI to "talk" to the custom data model, you must generate the Data Model-Specific Integration Class. This class (often referred to as the "Access Class") handles the mapping between the UI's GenIL layer and the underlying MDG staging tables.

Why the other options are incorrect:

A. Generate implementation classes (BAdI) using Floorplan Manager:
FPM is a UI framework for layout and events; it does not generate the data-binding implementation classes. The classes are generated based on the MDG Data Model, not the Floorplan Manager itself.

C. Create MDG communicator settings:
The MDG Communicator is primarily used to manage the behavior of the "Action Bar" (buttons like Submit, Approve, etc.) within the workflow. While important for the process, it is not a core step for creating the simple UI structure used to maintain the actual data fields.

Reference:
SAP Help Portal: Master Data Governance > Configuration of Master Data Governance > General Settings > UI Modeling.

A.   Attributes of the entity

B.   Relationship between entity types

D.   Storage and use type of the entity

Explanation:

When you create or enhance a data model in SAP MDG (Transaction USMD_MODEL), you are defining the metadata structure. This involves specifying how data is stored, its characteristics, and how it relates to other objects.

A. Attributes of the entity:
Once an entity is created, you define its Attributes, which represent the actual data fields (e.g., "Color," "Weight," or "Custom Classification"). These are assigned to the entity and can be defined as "Key" attributes or "Non-Key" attributes.

B. Relationship between entity types:
Entities do not exist in isolation. You must define Relationships to establish the hierarchy. This includes Leading relationships (defining the parent-child structure), Referencing relationships (for lookups), and Qualifying relationships.

D. Storage and use type of the entity:
This is the most critical property. You must choose between the four types:

Type 1: Changeable via Change Request; has its own database tables (e.g., Material, Supplier).
Type 2: Changeable without Change Request (Check table).
Type 3: Not changeable via MDG; used as a reference (e.g., Country codes).
Type 4: Part of another entity (e.g., Plant data belonging to a Material).

Why the other options are incorrect:

C. Configuration of the entity:
This is a vague term. In SAP MDG, "Configuration" usually refers to UI Configuration or Process Configuration (like Change Request steps). These are external to the Data Model definition itself.

E. Change request types of the entity:
Change Request Types are part of Process Modeling, not Data Modeling. While an entity is eventually assigned to a CR Type so it can be governed, this assignment happens in a different area of the IMG (Customizing), not within the entity property definition in USMD_MODEL.

Reference:
SAP Help Portal: Master Data Governance > Configuration of Master Data Governance > General Settings > Data Modeling > Edit Data Model.