Implement idempotent design and have Sales Representatives retry order(s) in
question.

Explanation:

When a network drop causes a lost acknowledgement, retries can inadvertently create a second order unless your integration is idempotent (“at most once” semantics). By assigning each order a unique message ID (or idempotency key) that your manufacturing system tracks, repeated submissions with the same key are recognized and ignored. Salesforce and many REST best-practices guides recommend this idempotent receiver pattern to guarantee single delivery even if clients retry. This allows reps to simply retry without fear of duplicates, and it builds robust fault-tolerance without custom polling or batch-reconciliation jobs.

Change Data Capture Events

High Volume Platform Events

Explanation:

To minimize data loss across days-long disconnects, you need durable, high-retention channels. Change Data Capture (CDC) and High-Volume Platform Events are both implemented on the High-Volume Streaming API, offering a 72-hour retention window and replay-ID-based durable subscriptions. In contrast, Generic or PushTopic events (standard-volume) expire after 24 hours and have lower throughput. Choosing CDC and high-volume Platform Events ensures that even if a client reconnects infrequently, it can reliably replay missed changes without data loss.

Platform Events

Explanation:

Of all event types, High-Volume Platform Events provide the longest built-in retention—up to 72 hours—so subscribers can reconnect within three days and still retrieve missed messages. Change Data Capture events are implemented as high-volume PEs behind the scenes, but the exam choice is explicitly “Platform Events.” Generic and standard-volume events only persist for 24 hours, and Apex callouts can’t buffer for days. By modeling your notifications as high-volume Platform Events, you get guaranteed at-least-once delivery with multi-day replay support.

Outbound Messaging, which will automatically handle error retries to the service.

Explanation:

Salesforce Outbound Messaging delivers a SOAP message to your finance endpoint and automatically retries on failure for up to 24 hours, giving you built-in delivery guarantees without custom Apex. Each message contains its own unique notification ID, and the service must acknowledge receipt with a 2xx HTTP response; otherwise, Salesforce queues and retries until it succeeds or drops after the retry window. This “fire-and-forget” pattern offloads retry logic to the platform and gives you near-exactly-once semantics as long as your endpoint is idempotent and acknowledges duplicates idempotently.

Impact of deleted records on system functionality.

Ability to delete personal data in every system.

Feasibility to restore deleted records when needed.

Explanation:

Under GDPR‐style data protection laws, “erasure” isn’t just a one-click delete—it requires careful coordination across every data store and backup to ensure compliance and operational continuity. First, you must be able to delete personal data in every system (CRM, Commerce Cloud, ERP, legacy mainframes, backups) so that a deletion request truly removes the subject’s information everywhere. Second, you need to assess the impact of deleted records on system functionality—for example, will orphaned orders, service cases, or analytic summaries break if the customer record is purged? This assessment drives exception handling and fallback designs. Third, you must evaluate the feasibility to restore deleted records to recover from accidental erasures or to comply with other legal holds—this includes designing audit logs or isolated recovery copies that respect data-minimization while still enabling rollback when legitimately needed.

Integrating Salesforce with Email Management System, Order Management System and Case Management System.

Explanation:

When Salesforce becomes the central case management platform, it must exchange data with:

→ Email Management System – to capture inbound customer emails as cases and push outbound responses back into users’ mailboxes.
→ Order Management System – so agents can reference order history, shipment details, and billing context when resolving order-related cases.
→ Existing Case Management System – to migrate legacy case records or synchronize ongoing cases, ensuring seamless continuity and archival access.

Other landscape elements like data warehouses are downstream analytics targets rather than part of transactional case workflows. Order Management and Email are mission-critical for day-to-day support operations, while the legacy Case Management system holds the historical data that agents still need. Choosing these three ensures you address both the operational inputs (emails, orders) and the data migration/synchronization requirements for cases.

SAML SSO and just-in-time provisioning

OpenId Connect Authentication Provider and just-in-time provisioning

Explanation:

To provide instant community access on first login, Salesforce must auto-provision users when they authenticate via SSO.

→ SAML SSO + JIT: You configure a SAML identity provider and enable Just-in-Time provisioning so that Salesforce consumes assertion attributes (e.g., Federation ID) to create the user, contact, and profile in one transaction.
→ OpenID Connect + JIT: You set up an OpenID Connect Authentication Provider in Setup and implement a Registration Handler class (Auth.RegistrationHandler) that Salesforce invokes on login, using the ID token claims to spin up the user record automatically.

Without JIT, you’d force users through a manual registration flow or pre-provisioning process, delaying access and complicating self-registration.

Build Batch Retry & Error Handling using BatchApexErrorEvent.

Explanation:

Salesforce’s BatchApexErrorEvent is a built-in platform event that fires whenever a batch Apex job fails or throws an unhandled exception. By subscribing to this event—either in Apex (trigger on the event) or via middleware—you can automatically detect failures in your daily invoice generation and implement retry logic or alerting without embedding complex error-handling inside the batch itself. This decouples your business logic from the resilience framework and leverages Salesforce’s event-driven model. A pure “in-job” retry loop risks hitting governor limits or masking systemic issues, and a simple report can’t react in real time. Events give you both visibility and automation around failure recovery for robust, scalable batch processing.

Create a special user solely for the integration purposes.

Explanation:

The architect should first create a dedicated integration user (D) rather than using an existing admin user (A) or relying on SSO (B) or network security (C). A dedicated integration user follows the principle of least privilege, ensuring the service has only the necessary permissions. This approach improves security (reduced attack surface), auditability (clear separation of integration activities), and stability (avoids disruptions from credential changes). While SSO or network-based authentication might supplement this, they aren't substitutes for a properly scoped integration user. Salesforce best practices explicitly recommend dedicated integration users for API access to avoid coupling integrations with human user accounts.

Sum of A and H

Explanation:

The user-perceived response time is the delta between the initial request (A) and the final UI update (H). Steps B–G represent backend asynchronous processes (e.g., parallel API calls to on-premise/3rd-party systems) that don't block the UI. While these steps contribute to data freshness, they don't affect the user's perception of responsiveness. The diagram implies A and H are the only synchronous touchpoints from the user's perspective. This aligns with frontend performance monitoring principles, where "time to first render" (A) and "time to final interaction" (H) are critical metrics.

Fire and Forget

Explanation:

When Salesforce publishes a Platform Event and a remote system subscribes to it, the communication follows a Fire and Forget pattern. Salesforce emits the event without waiting for a response from the subscriber. This decouples systems and supports scalability, but also means there's no delivery guarantee or acknowledgment within the platform. It's suitable for event-driven architectures where real-time responsiveness is desired, and the receiving system is responsible for error handling and retries.

Invoke middleware service to retrieve valid shipping methods.

Use middleware to abstract the call to the specific shipping services.

Explanation:

Since services vary frequently across countries, hardcoding options (like picklists) isn't scalable. Middleware offers a flexible, centralized abstraction layer that hides the complexity of integrating with multiple shipping providers. It can dynamically return the available options based on country and invoke appropriate services without requiring Salesforce to manage service-specific logic. Platform Events are not suited for this synchronous UI-based interaction, and picklists lack the dynamism needed.