Bulk API, Streaming API, Apex REST API, Analytics REST API

Explanation

NTO’s integration design must efficiently handle a one-time load of over 11 million records, push real-time change alerts to three downstream systems, securely expose custom logic to five external apps, and automate nightly data processes. The optimal API set leverages asynchronous bulk loading, event-driven streaming, lightweight secure REST endpoints, and Data Cloud scheduling capabilities for end-to-end governance.

✅ Correct Option: C – Bulk API, Streaming API, Apex REST API, Analytics REST API
Bulk API supports high-volume initial data ingestion with parallel job processing and automatic chunking for millions of records. Streaming API (PushTopic or Platform Events) delivers instant notifications of Account/Contact changes to external systems without polling. Apex REST API provides secure, JSON-based exposure of custom business logic using OAuth 2.0 and named credentials. Analytics REST API enables programmatic scheduling of Data Cloud dataflows, recipes, and sync operations nightly.

❌ Incorrect Option: A – Bulk API, Chatter REST API, Apex SOAP API, Tooling API
Chatter REST API focuses on social feeds and collaboration—not record-level change detection or notifications. Apex SOAP API is deprecated for new development; it’s verbose, slower, and harder to secure than REST. Tooling API manages metadata and CI/CD—not data movement or business logic.

❌ Incorrect Option: B – Bulk API, Chatter REST API, Apex REST API, Analytics REST API
Substitutes Streaming API with Chatter REST API, which cannot monitor or push DML events. Fails the real-time notification requirement entirely.

❌ Incorrect Option: D – Bulk API, Streaming API, Apex SOAP API, Analytics REST API
Replaces Apex REST API with outdated Apex SOAP API—leading to larger payloads and complex WSDL management. SOAP lacks modern security and performance advantages of REST for external app integration.

📚 Reference:
Introduction to Bulk API 2.0 and Bulk API
Getting Started with Streaming API
Exposing Apex Classes as REST Web Services
CRM Analytics REST API Overview

Develop custom APIs on the company's network that are invokable by Salesforce.

Deploy MuleSoft to the on-premise network and design externally facing APIs to expose the data.

Explanation

The core requirement is to expose data from on-premise applications to Salesforce in real-time. The on-premise systems are protected, so the solution must facilitate secure, external access without compromising the corporate network.

Let's evaluate why the correct answers work and why the others do not:

B. Develop custom APIs on the company's network that are invokable by Salesforce.
This is a foundational and correct approach. It involves creating custom REST or SOAP API endpoints within the corporate firewall that expose the specific data needed from the on-premise applications. Salesforce can then call these APIs directly (using Apex or a low-code tool) to retrieve data in real-time. This provides maximum control and is a direct implementation of the required integration pattern.

C. Deploy MuleSoft to the on-premise network and design externally facing APIs to expose the data.
This is also correct and is a more robust, enterprise-grade version of option B. MuleSoft, an integration platform owned by Salesforce, acts as an API-led connectivity layer. Deploying it on-premise allows it to connect securely to the backend systems. You then design and publish managed, well-documented APIs that Salesforce can call. This approach provides benefits like built-in security, transformation, orchestration, and reusability that pure custom code (option B) might lack.

Why the other options are incorrect:

A. Develop an application in Heroku that connects to the on-premise database via an ODBC string and VPC connection.
This is incorrect and architecturally risky. Directly connecting an external application to the production database via ODBC bypasses the application logic and data layer, which is a major security anti-pattern. It can lead to data corruption, performance issues, and schema lock-in. The correct approach is to integrate through APIs provided by the application, not directly with its database.

D. Run a batch job with an ETL tool from an on-premise server to move data to Salesforce.
This is incorrect because it violates the core requirement of real-time access. ETL (Extract, Transform, Load) jobs are batch-oriented; they run on a schedule (e.g., every hour or night). This would result in stale data within Salesforce, which does not fulfill the requirement for a "unified user experience" with current information.

Key Concept
The key concept tested here is the selection of the Real-Time Integration Pattern, specifically the API-led Connectivity approach for accessing data from secured, on-premise systems.
An Integration Architect must recognize that real-time access requires a synchronous, request-response mechanism. The solution must create a secure gateway (the API) that exposes the on-premise data without directly exposing the database itself, adhering to principles of loose coupling and security.

Reference
This aligns with the standard integration patterns documented by Salesforce and MuleSoft. The official Salesforce Integration Architecture documentation advocates for the "Virtual Data Integration" or "Direct Data Access" pattern for real-time scenarios to avoid data duplication and latency. Using MuleSoft as an integration layer is a canonical example of the API-led connectivity model, which is the recommended approach for creating a structured, reusable, and secure integration framework.

Inability to query event messages using SOQL

Inability to create a Lightning record page for platform events.

When you delete an event definition, it's permanently removed and can't be restored.

Explanation

Platform Events are ideal for real-time, event-driven integrations, but have specific limitations the Integration Architect must consider.

A. Inability to query event messages using SOQL
Correct

Platform Events are not stored like regular objects.
You cannot use SOQL to query past events.
Use Replay ID or Event Monitoring for historical access.
Critical for expectation setting — no ad-hoc querying.

C. Inability to create a Lightning record page for platform events Correct

No standard detail/record pages for Platform Events.
Cannot build Lightning App pages with related lists or forms.
UI interaction limited to custom components or Flows.

D. When you delete an event definition, it's permanently removed and can't be restored Correct

Hard delete — no recycle bin.
All subscribers lose the channel.
Must version control event definitions in source control (e.g., SFDX).

Why B and E are incorrect

B. Subscribe to an AssetToken Event stream to monitor OAuth 2.0 authentication activity
→ Wrong — AssetToken events are for File Connect, not OAuth monitoring.
Use Event Monitoring or Login Forensics for auth activity.

E. You can use Event Monitoring to track user activity, such as logins and running reports
→ Misleading — This is true, but not a limitation of Platform Events.
It’s a feature of Event Monitoring, not a consideration when recommending Platform Events.

References
Salesforce Help: Platform Events Limitations
Developer Guide: Considerations for Defining and Publishing Platform Events

Exam Tip:
When recommending Platform Events, always highlight:
No SOQL (A)
No record pages (C)
Permanent delete (D)

Evaluate current and future data and system usage and then identify potential integration requirements to Salesforce.

Explanation

The core of an Integration Consultant's role, especially in the planning phase, is to first understand the business processes and data flows before recommending specific tools or technologies. The other options, while potentially part of the final solution, are premature without this foundational analysis.

Let's evaluate each option:

A. Plan for migration of customer and sales data across systems on a regular basis to keep them in sync.
This is incorrect. Regular data migration via ETL is a batch-oriented approach that will lead to data silos and stale information. The requirement for a "single view of their customers" implies a need for real-time or near-real-time data access, which batch syncs cannot reliably provide. This approach also creates data duplication and complicates determining the system of record.

B. Evaluate current and future data and system usage and then identify potential integration requirements to Salesforce.
This is the correct and foundational step. An Integration Consultant must first conduct a thorough discovery to answer key questions: Which system is the master for each data type (e.g., ERP for product inventory, Outlook for contacts)? What business events trigger data flow (e.g., a new order in Salesforce should update inventory in the ERP)? What are the real-time vs. batch needs? What are the future growth plans? Only after this analysis can a proper integration strategy be formulated.

C. Explore Out of box Salesforce connectors for integration with ERP, Marketing and Microsoft Outlook systems.
This is a good subsequent step, but it is not the first consideration. Exploring specific connectors is a solutioning activity that should only happen after the integration requirements (from option B) are understood. Jumping straight to tools without a strategy can lead to a poorly architected solution that doesn't meet all business needs.

D. Propose a middleware system that can support interface between systems with Salesforce.
Similar to option C, this is a potential implementation step, not the initial consideration. Proposing a middleware platform like MuleSoft is a significant architectural decision. It should be a recommendation that comes out of the evaluation in option B, not a pre-determined starting point. For some needs, point-to-point connections or platform-native tools (like Salesforce Connect) might be more appropriate.

Key Concept
The key concept is the Integration Discovery and Strategy Phase. Before any technical solution is chosen, an architect must perform a comprehensive analysis of the current state, including data models, system dependencies, business processes, and future-state goals. This ensures the integration architecture is business-driven, scalable, and addresses the root need for a "single view of the customer" rather than just connecting systems.

Reference
This approach is aligned with established integration methodology, such as the MuleSoft API-led connectivity approach, which begins with a "discover" phase to uncover and define all underlying systems and processes. The official Salesforce Architecture documentation also emphasizes starting with a "Current State Architecture" assessment to understand all applications, data, and processes before designing the "Future State." This foundational work is critical to avoid costly rework and ensure the final solution truly meets the business objective of a unified customer view.

Explanation:

The key to this question lies in the business objective: "to implement Salesforce to support case management." An Integration Architect must evaluate systems that will be directly involved in the end-to-end case management process to provide a unified agent experience and a complete customer view.
Salesforce Service Cloud is a full-featured Case Management system. Therefore, integrating it with the existing Case Management System would be redundant and create data duplication, conflicting processes, and a poor agent experience. The architect's goal is to consolidate case management into Salesforce, not to integrate two parallel case systems.
Here’s why the systems in option D are the correct ones to evaluate for integration:

1. Email Management System: This is a critical integration. Cases are often created from customer emails. Salesforce must integrate with the existing email system to:
→ Ingest emails and automatically create cases in Salesforce.
→ Send outbound emails from within Salesforce (e.g., agent responses, notifications) using the corporate email system.
→ Track email threads and attachments associated with a case record.
Without this integration, the case management process would be siloed and inefficient.

2. Order Management System: To effectively support customers, service agents need context. A common reason for a customer to open a case is to inquire about an order (e.g., status, return, problem). Integrating Salesforce with the Order Management System allows agents to:
→ View order history, status, and details directly on the case layout in Salesforce.
→ Initiate processes like returns or exchanges directly from the case.
This integration is essential for providing fast, informed, and effective customer service.

3. Data Warehouse (Not a primary integration for case management): While a Data Warehouse is important for analytics and historical reporting, it is not part of the real-time, operational flow of case management. Pushing data to the warehouse is typically a separate, asynchronous process (e.g., nightly ETL jobs) and is not required for the core functionality of creating, updating, and resolving cases. Therefore, it is a lower priority for this specific evaluation.

Why the other options are incorrect:

A. Integrating Salesforce with Order Management System, Email Management System and Case Management System: This is incorrect because it includes integrating with the existing Case Management System. Since Salesforce is the new case management system, integrating with the old one suggests a co-existence strategy, which is architecturally unsound for this scenario. The goal should be to decommission the old system, not integrate with it.

B. Integrating Salesforce with Order Management System, Data Warehouse and Case Management System: This is incorrect for two reasons. It includes the redundant Case Management System and prioritizes the Data Warehouse over the more critical Email Management System. Email is a direct channel for case creation, while the data warehouse is for reporting.

C. Integrating Salesforce with Data Warehouse, Order Management and Email Management System: This option correctly excludes the old Case Management System and includes Email and Order Management. However, it is less correct than D because it includes the Data Warehouse instead of the Case Management System. While not ideal, an architect might still need to evaluate a migration path from the old system, making it a more relevant consideration than the data warehouse. Option D's list is the most directly relevant to the operational process.

Key Architectural Principle:
An Integration Architect must first identify systems of record and systems of engagement. For this project:
→ Salesforce is becoming the System of Engagement for service agents and the System of Record for Cases.
→ The Order Management System remains the System of Record for orders.
→ The Email System is a System of Engagement for communication.
The integration strategy focuses on bringing the data from these systems of record into the system of engagement to empower agents.

Reference:
Salesforce Integration Architecture Guidelines: The evaluation focuses on "key master data" and "operational systems" that are part of the business process being implemented in Salesforce.
Trailhead Module: "Define Your Integration Strategy" emphasizes understanding the business process (Case Management) and identifying which systems hold the data needed to support that process.