Free Salesforce-Platform-Integration-Architect Practice Test Questions (2026)

Named Credentials

Enterprise ESB

Explanation

The URL changed unexpectedly, breaking a business-critical currency exchange service. The goal is zero/minimal downtime when such changes occur.

A. Named Credentials
Correct

Stores the endpoint URL in one place.
Update the URL once in Named Credentials → all callouts (Apex, Flow, etc.) instantly use the new URL.
No code redeploy, no user impact.
Supports authentication (OAuth, API keys) too.

D. Enterprise ESB
Correct

Enterprise Service Bus (e.g., MuleSoft, Boomi) acts as a proxy layer.
Salesforce calls a stable ESB endpoint — ESB forwards to the real (changeable) service.
URL changes are handled outside Salesforce, zero impact on org.

Why B and C are incorrect

B. Remote Site Settings
Only allows outbound HTTP — does not abstract the URL.
You’d still have to update hardcoded URLs in Apex/Flows → downtime.

C. Content Security Policies
Controls browser-side content (e.g., iframes, scripts).
Irrelevant to server-to-server API callouts.

References
Salesforce Help: Named Credentials
Architect Guide: Integration Patterns – Remote Callout
MuleSoft: ESB as abstraction layer

Exam Tip: Sudden URL change? → Named Credentials (A) or ESB (D) to avoid hardcoding and enable fast fixes.

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.

Due to high volume of records, a third party integration tool is required to stage records off platform.

Explanation:

In this scenario, Salesforce needs to send large volumes of data (around 2 million records per day) to an on-premise, home-grown system that resides behind a corporate firewall. The data movement is one-way and not real-time, meaning the solution should focus on reliability, scalability, and efficiency, rather than synchronous responsiveness.

Salesforce is not designed to handle direct outbound transfers of such large data volumes using callouts or APIs. Each API callout has limits on execution time, payload size, and concurrency. Pushing millions of records per day directly from Salesforce would quickly exceed governor limits and daily callout limits, and would be highly inefficient.

To overcome these challenges, an external or middleware integration layer (such as Mulesoft, Informatica, Dell Boomi, or any ETL tool) is commonly introduced.

This middleware can:

Stage data off-platform using exports from Salesforce (e.g., via Bulk API or scheduled data extract).
Transform and aggregate the data before delivery.
Push it to the on-premise system over a secure network path without breaching firewall constraints.
Handle retry logic, queuing, and monitoring independently of Salesforce limits.
This makes the approach both scalable and secure for high-volume, asynchronous, one-way integrations.

Incorrect Options :

A. Due to high volume of records, number of concurrent requests can hit the limit for the REST API call to external system.
Incorrect because Salesforce should not make direct REST calls for millions of records per day — this would be inefficient and often blocked by firewalls.

C. Due to high volume of records, the external system will need to use a BULK API REST endpoint to connect to Salesforce.
Incorrect direction — Bulk API is for importing into Salesforce, not exporting out of it.

D. Due to high volume of records, Salesforce will need to make a REST API call to external system.
Incorrect because the external system is behind a firewall, so Salesforce cannot directly initiate these connections securely or efficiently.

In summary:
The right approach is to use a middleware or staging integration tool that can securely extract, store, and deliver large data sets from Salesforce to the on-premise system, ensuring both performance and compliance with Salesforce’s API and callout limits.

To subscribe to an event, the integration user in salesforce needs read access to
theevent entity.

To publish an event, the integration user in salesforce needs create permission on the event entity.

Error handling must be performed by the remote service because the event is effectively handed off to the remote system for further processing.

Explanation

Platform Events use an event-driven architecture characterized by asynchronous, decoupled communication. The architect must consider the operational and security requirements specific to this pattern.

D. To publish an event, the integration user in Salesforce needs create permission on the event entity.

Publishing Security:
The Salesforce user or integration mechanism (e.g., Apex, Flow, or API call) that sends the event needs the standard Create permission on the custom Platform Event object, just like creating any custom object record.

A. To subscribe to an event, the integration user in Salesforce needs read access to the event entity.

Subscribing Security:
Any subscriber (e.g., an external system connected via CometD, or an internal Apex trigger/Flow) must have Read access to the Platform Event object to receive and process the event messages.

E. Error handling must be performed by the remote service because the event is effectively handed off to the remote system for further processing.

Decoupling and Error Handling:
Platform Events are fire-and-forget. When Salesforce publishes the event, it doesn't wait for a response from the external system. Therefore, Salesforce cannot natively manage the external system's processing errors (e.g., if the external service is down or fails a business validation). The remote system is responsible for consuming the event, implementing its business logic, and handling any resulting failures (e.g., logging, retries, or sending a compensating event back to Salesforce).

❌ Why the Other Options are Incorrect

B. Salesforce needs to be able to store information about the external system in order to know which event to send out.

Event-Driven Principle:
This statement is incorrect. Platform Events promote decoupling. The publisher (Salesforce) does not and should not know or care who the subscribers are or what systems are listening. It simply publishes the event, and any interested party consumes it.

C. External system needs to have the same uptime in order to be able to keep up with Salesforce Platform Events.

Asynchronous Benefit:
This is incorrect and defeats the purpose of an asynchronous pattern. The primary advantage of Platform Events is that the external system does not need to have the same uptime. If the external system is down, the events are held in the event bus for up to 3 days (depending on the event type), and the subscriber can catch up when it comes back online. The systems are not tightly coupled by uptime requirements.

Summary:
The Integration Architect designs secure, scalable, and reliable solutions to connect Salesforce with other systems. This involves selecting the correct integration pattern (e.g., synchronous, asynchronous, bulk), the appropriate Salesforce API (e.g., REST, Bulk, UI, Platform Events), and implementing robust security models (OAuth, mTLS, DMZ) while always considering system limits and effective error handling.

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)

Streaming API

Explanation

The question specifies that the Integration Architect has already recommended using a Salesforce Platform Event to provide a near real-time feed. The key is to understand which API is specifically designed to consume or subscribe to these events from an external system.

Let's evaluate the options:

A. Tooling API:
This is incorrect. The Tooling API is used for building custom development tools and applications that manage Salesforce metadata. It is not designed for subscribing to real-time event feeds.

B. Streaming API:
This is correct. The Streaming API is the generic mechanism for external clients to subscribe to events. It uses the CometD protocol to maintain a long-lived connection, allowing the learning system to listen for and receive Platform Event messages the moment they are published in Salesforce. This provides the "near real-time" feed that UC requested.

C. REST API:
This is incorrect for the subscription role. The REST API can be used to publish a Platform Event from an external system to Salesforce, but it cannot be used to listen for events. An external system cannot use the REST API to get a continuous, real-time feed of events; it would have to constantly poll, which is inefficient and not real-time.

D. SOAP API:
This is incorrect for the same reason as the REST API. The SOAP API can be used to publish events to Salesforce, but it cannot act as a subscriber to receive a real-time push of events.

Key Concept

The key concept is the distinction between publishing and subscribing to Platform Events.
Publishing an Event: Sending an event message into the Salesforce Event Bus. This can be done from Apex, Process Builder, Flow, or externally via the REST API or SOAP API.
Subscribing to an Event: Listening for and receiving event messages from the Salesforce Event Bus. This is done exclusively through the Streaming API for external clients.
The learning system needs to subscribe to the Student Registration event, making the Streaming API the only correct choice.

Reference
This is a fundamental aspect of the Salesforce event-driven architecture. The official Salesforce "Streaming API" Developer Guide states that it "enables you to receive notifications for changes in Salesforce data... using a publish-subscribe model." It is the designated API for external systems to subscribe to Platform Events, PushTopics, and Generic Streaming channels to receive real-time data.

Handle verification process error in the Verification Webservice API in case there is a connection issue to the Webservice if it responds with an error.

Explanation:

This scenario involves real-time credit verification while a support agent is interacting directly with a customer. Because the credit check determines whether the bank account can be opened, the agent must see an immediate response: success or failure.

Therefore, the integration must use Request and Reply style communication and must include proper error handling, such as when:

The external verification service is unreachable
It returns an error or exception response
Network connectivity fails
Error feedback must be returned immediately to the agent, not delayed or queued.

✅ Correct Answer(s)

B. Handle verification process error in the Verification Webservice API in case there is a connection issue to the Webservice if it responds with an error.
✅ Proper synchronous error handling ensures UI can display meaningful errors to agents.
If the external service returns an error or the connection fails, Salesforce must catch it and inform the user instantly.

C. Handle integration errors in the middleware in case the verification process is down, then the middleware should retry processing the request multiple times.
✅ Middleware should handle transient network/service failures and retry before returning an error response.
If retry attempts fail, then Salesforce must show the failure to the agent.

❌ Incorrect Options

A. In case the verification process is down, Use mock service to send the response to the agent.
Mocking is for testing, not production error handling.

D. In case the verification process is down, use fire and forget mechanism instead of request and reply…
Fire-and-forget does not allow immediate decisioning. The agent would not receive a timely result — unacceptable for credit-checking.

✅ Final Answer:
B and C

Case Management System

Sales Activity System

Email Marketing System

Explanation 💡

The primary driver for retiring these systems is the customer's goal to "Leverage Salesforce capabilities for Marketing, Sales and Service processes" (Goal 2). This indicates that the functionalities provided by these legacy systems will be natively replaced by standard Salesforce Clouds.

Correct Answers ✅
B. Case Management System
C. Sales Activity System
D. Email Marketing System

Rationale
B. Case Management System:
This functionality is natively replaced by Salesforce Service Cloud, which handles customer service issues, support cases, and entitlements.

C. Sales Activity System:
This functionality is natively replaced by Salesforce Sales Cloud, which manages leads, opportunities, accounts, and all sales-related activities.

D. Email Marketing System:
This functionality is natively replaced by Salesforce Marketing Cloud (or Marketing Cloud Account Engagement/Pardot), which provides comprehensive email campaign management and marketing automation.

Incorrect Options ❌
A. Order Management System
E. Quoting System

Rationale
These systems cannot be retired because the customer's goal explicitly states: "Reuse Enterprise capabilities built for Quoting and Order Management processes" (Goal 3).

Integration Strategy:
When a customer chooses to reuse existing back-office systems, the Integration Architect must design an integration strategy for Salesforce to communicate with these systems. These systems are kept because they often house complex, mission-critical financial and fulfillment logic that the customer is not ready or willing to migrate to Salesforce.

Focus on Integration, Not Replacement:
This scenario requires integration, where Salesforce acts as the system of engagement (Sales, Service, Marketing), leveraging the legacy systems as the systems of record for order and quote execution.

Key Concepts 📖

System of Engagement vs. System of Record:
Salesforce is generally implemented as the System of Engagement (where users interact), while complex, highly functional back-office systems (like OMS and Quoting) remain the System of Record (where master data and transactional logic reside) and must be integrated.
Salesforce Cloud Capabilities:
This decision relies on knowing the core native capabilities of Sales Cloud, Service Cloud, and Marketing Cloud and how they replace common legacy functions.

Connect REST API

Explanation

The requirement is:
When a Chatter post with #thanksNTO is created → automatically post to Twitter.
This is a real-time, event-driven integration triggered by a Chatter feed item.

Why Connect REST API is the Right Choice
The requirement involves real-time detection of a Chatter post containing the #thanksNTO hashtag and automatically posting it to Twitter. This is a Chatter-driven, outbound social integration. The Connect REST API is specifically designed for such scenarios. It provides full access to Chatter feeds, feed items, and social publishing capabilities within Salesforce. Using this API, the integration can monitor feed activity, extract posts with the hashtag, and initiate cross-posting to external platforms like Twitter — all while maintaining user context and security.

How It Works in Practice
An Apex trigger on the FeedItem object listens for new Chatter posts. When a post includes #thanksNTO, the trigger uses Connect REST API endpoints (under /connect/) to retrieve the full post context, including author and community details. From there, a secure HTTP callout (via Named Credential) sends the content to the Twitter API. The Connect REST API ensures the action is user-aware and supports community-specific feeds, making it ideal for NTO’s custom mobile app interacting with Community Cloud.

Why Other Options Fail

REST API (B):
This is the general Salesforce REST API for CRUD operations on standard and custom objects. It does not provide native access to Chatter feeds or social publishing features. You’d need complex workarounds, making it inefficient and unsupported.

Streaming API (C):
Excellent for real-time notifications (e.g., PushTopic, Platform Events), it can alert when a Chatter post is made. However, it is inbound-only — it cannot post to Twitter. It’s a detection tool, not a publishing mechanism.

Apex REST (D):
This allows you to expose custom endpoints in Salesforce for external systems to call. It is inbound, not outbound. It cannot initiate a post to Twitter — it’s the wrong direction

Official References
Salesforce Help: Connect REST API Developer Guide
Trailhead: Integrate with External Social Networks

Exam Success Tip
For any integration involving Chatter + external social networks (Twitter, Facebook, etc.), the answer is always Connect REST API. It’s the only API that bridges Salesforce Chatter with third-party social platforms securely and natively.

Use Salesforce Connect to display the financial transactions as an external object.

Explanation

The core requirement is to allow community users to view their financial transactions, which are mastered in a high-volume, state-of-the-art core banking system processing 10 million transactions daily. The key architectural principle here is to avoid duplicating this massive, sensitive, and frequently updated data into Salesforce.

Let's evaluate the options:

A. Use Salesforce Connect to display the financial transactions as an external object.
This is the correct approach. Salesforce Connect with external objects implements a data virtualization pattern. It allows the community portal to display data that resides in the core banking system in real-time without storing a copy in Salesforce. The data is fetched on-demand when a user loads the page, ensuring they always see the most current information. This is ideal for high-volume, transactional data that is mastered elsewhere.

C. Use Salesforce External Service to display financial transactions in a community lightning page.
This is incorrect for this specific use case. External Services is designed to call external APIs (like REST endpoints) to execute actions or retrieve data that is then processed in Apex or Flows. It is excellent for invoking specific functions but is not the optimal tool for directly presenting a large, queryable list of transactional records in a standard UI. External Objects provide a much more seamless, native Salesforce experience for viewing and searching records.

D. Use Iframe to display core banking financial transactions data in the community.
This is incorrect and an anti-pattern. While technically possible, an iFrame creates a disjointed user experience that is not mobile-friendly and breaks the native look and feel of the community. More importantly, it introduces significant security complexities, as the core banking system would need to be directly exposed to the internet and manage its own authentication separately from the Salesforce community, which is a major security risk for a financial institution.

Key Concept
The key concept is Data Virtualization vs. Data Replication.
Data Replication (the alternative not listed):
This would involve building ETL jobs to copy the 10 million daily transactions into Salesforce objects. This is a poor choice as it creates data latency, consumes massive data storage, and introduces a complex synchronization overhead.
Data Virtualization (Option A):
This leaves the data in its source system (the core banking system) and provides a real-time, virtual "window" to it from within Salesforce. This ensures data is always current, avoids data duplication, and is perfectly suited for high-volume, externally mastered data that needs to be viewed in the Salesforce UI.

Reference
This recommendation is based on the official Salesforce integration pattern known as "Virtual Data Integration with External Objects." The Salesforce documentation for Salesforce Connect and External Objects explicitly supports this use case for providing real-time read-only (or read-write) access to data stored in an external system. This is the standard, supported method for building a unified customer view without replicating operational system-of-record data, which is a critical requirement in the financial services industry.