Courseiva
Master Data Management →mediumMultiple Choice

SF-Data-Arch Master Data Management Practice Question

Northern Trail Outfitters uses Salesforce as its system of entry for accounts and has a legacy ERP that remains the system of record for billing. The data architect must ensure that when an account's billing address changes in Salesforce, the ERP is updated within near real time, and when the ERP changes a credit limit, Salesforce reflects it within the same window. No middleware is currently in place. Which approach should the architect recommend?

⚠ Common exam trap

The trap here is assuming that Salesforce Connect external objects or a nightly batch job can satisfy bidirectional near real time synchronization, when external objects are read-only for external data and batch jobs cannot meet the latency requirement.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Implement a bidirectional integration using Platform Events and Change Data Capture, with an external subscriber handling ERP writes and publishing ERP changes back as Platform Events.

Near real time bidirectional synchronization between Salesforce and an ERP without middleware is best achieved with Salesforce's native eventing: Change Data Capture streams Salesforce record changes, and Platform Events can carry ERP changes back. This decouples systems, preserves throughput, and supports the required latency. Batch or synchronous dual-write approaches either miss the latency target or create fragile coupling that undermines master data consistency.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

  • ✗

    Create a duplicate of each account in the ERP as an external object and use Apex triggers to write to both systems on every account save.

    Why it's wrong here

    Writing to two systems inside a trigger couples the user transaction to ERP availability and can cause governor limit failures or partial commits if the ERP callout times out. It also does not address ERP-originated changes flowing back into Salesforce. This synchronous dual-write pattern increases the risk of divergent master data rather than ensuring consistency.

  • ✗

    Schedule a nightly Apex batch job that exports updated accounts to CSV and the ERP imports them, with a reciprocal nightly import.

    Why it's wrong here

    A nightly batch exchange does not meet a near real time requirement, and CSV export/import introduces file handling, error recovery, and latency that would delay synchronization by hours. It also cannot guarantee ordering of changes across systems, so a credit limit change and an address change could overwrite each other, producing inconsistent master data across Salesforce and the ERP.

  • ✓

    Implement a bidirectional integration using Platform Events and Change Data Capture, with an external subscriber handling ERP writes and publishing ERP changes back as Platform Events.

    Why this is correct

    Change Data Capture publishes record changes from Salesforce in near real time, and Platform Events carry ERP-originated changes back into Salesforce. A subscriber can apply the ERP changes to accounts and publish credit limit updates as events, satisfying bidirectionality and low latency without middleware. This is the native Salesforce pattern for event-driven master data synchronization across systems.

  • ✗

    Configure Salesforce Connect with an OData adapter so Salesforce reads ERP billing records live and the ERP reads Salesforce accounts live.

    Why it's wrong here

    Salesforce Connect with OData provides real-time read access to external data without replication, but it does not push Salesforce-originated changes back into the ERP, and the ERP cannot natively read Salesforce objects as external tables. This scenario requires bidirectional write synchronization, which external objects do not deliver, so billing address updates would never reach the ERP.

Visual reference

Client Server SYN (seq=100) SYN-ACK (seq=200, ack=101) ACK (ack=201) Connection established — data transfer begins

About these practice questions

This SF-Data-Arch question is part of Courseiva's 222-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →

How Courseiva writes practice questions · Editorial policy

JA

Written and reviewed by Johnson Ajibi, MSc IT Security

Senior Network & Security Engineer · founder of Courseiva

Last reviewed September 2026 · checked against the official Salesforce exam blueprint

This SF-Data-Arch practice question is part of Courseiva's free Salesforce certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the SF-Data-Arch exam.