Pass the Salesforce Integration Architecture Designer Integration-Architect Questions and answers with CertsForce

The CIO's concern regarding "viability" and "scaling" is rooted in the risks associated with tightly coupled, point-to-point integrations. Using @future methods for direct callouts creates a "spaghetti" architecture where Salesforce must manage the specific endpoints, authentication, and error logic for every external system.

The architect should recommend implementing an Enterprise Service Bus (ESB). An ESB acts as a centralized middleware layer that provides mediation, routing, and orchestration. By moving the integration logic to an ESB, Salesforce only needs to send a single message to the bus. The ESB then takes responsibility for delivering that data to multiple business units and external systems. This decouples Salesforce from the downstream systems; if a target system changes its API or is replaced, only the ESB configuration needs to be updated, not the Salesforce Apex code.

While External Services (Option A) provide a low-code way to call APIs, they still represent point-to-point connections and do not solve the broader orchestration and scaling challenges. ETL tools (Option C) are designed for bulk data movement and would not satisfy the need for the near real-time updates that the existing callout logic likely supports. An ESB provides the "quality of service" features—such as guaranteed delivery, retries, and protocol transformation—that are necessary for a growing enterprise to maintain a stable and scalable integration landscape.

When integrating Salesforce with high-security enterprise systems like an Enterprise Billing System (EBS) and a Document Management System (DMS), the primary architectural concern is respecting the Enterprise security needs for access control. These systems often contain highly sensitive financial data and are governed by strict regulatory requirements (e.g., PCI-DSS or GDPR).

The integration consultant must evaluate how to extend existing enterprise identity and authorization policies to Salesforce users. This often involves a Identity Federation strategy using protocols like SAML 2.0 or OpenID Connect. Instead of maintaining separate credentials in Salesforce (which Option A suggests and is generally an "anti-pattern" for 10 million records), the consultant should consider using a central Identity Provider (IdP).

By considering enterprise security needs, the architect ensures that when a support agent clicks a link in Salesforce to view a bill, the request is authenticated against the enterprise's security gateway. This allows for Single Sign-On (SSO) while ensuring that authorization (who can see what) remains mastered in the source systems or the central IdP. Migration (Option C) is physically and technically unfeasible for systems handling 10 million customers' historical bills and real-time processing. The focused objective is to build a "window" into these systems from Salesforce while maintaining the integrity of the enterprise's existing security perimeter.

To translate abstract business needs into a functional Integration Architecture, an architect must move beyond "what" the business wants to "how" the data will technically flow. The details in Option B represent the fundamental building blocks of any integration design.

Source and Target Systems: Determining which systems are involved dictates the available APIs (REST, SOAP, Bulk) and required security protocols (OAuth, Mutual SSL).

Directionality: Knowing if the update is unidirectional or bidirectional is critical for record mastering, identifying the "System of Record," and preventing infinite data loops.

Data Volume: This is a primary driver for selecting the Integration Pattern. High volumes (millions of records) require the Bulk API, while low-volume, real-time updates are better suited for Streaming or REST APIs.

Transformation Complexity: If data must be heavily massaged or merged from multiple sources, it justifies the need for Middleware (ESB/iPaaS).

Option A focuses on user interface and licensing, which are implementation details rather than architectural integration requirements. Option C deals with project management and resource allocation. While these are important for the project's success, they do not help the architect decide between a Request-Reply or Fire-and-Forget pattern. By focusing on systems, data direction, and volume, the architect ensures that the proposed solution is technically viable, scalable, and adheres to Salesforce platform governor limits.

When evaluating a current system landscape for a Salesforce implementation, an Integration Architect’s primary goal is to align the platform’s native capabilities with the existing architecture to determine which systems will be replaced, retired, or integrated. Based on the provided diagram (image_69c0fd.png), the landscape consists of an Email Management System, an Order Management System, a Case Management System, and a Data Warehouse used for Business Intelligence.

In a scenario where an enterprise is implementing Salesforce to support Case Management (Service Cloud), Salesforce natively provides the robust capabilities required to serve as the new "System of Record" for customer support interactions. Consequently, the legacy Case Management System is typically targeted for retirement. The architect’s evaluation therefore focuses on the necessary integration points with the systems that will coexist with the new Salesforce instance to ensure a unified agent experience.

As outlined in standard Salesforce Integration Architecture frameworks, the following evaluations are critical:

Order Management System (OMS): Salesforce must integrate with the OMS so that service agents can view real-time order history, shipping status, and line items directly within the Case record, often using patterns like Request-Reply or Data Virtualization.

Email Management System (EMS): To support Omni-Channel service, Salesforce needs to integrate with the EMS (via Email-to-Case or a Marketing Cloud connector) to ensure that all customer communications are captured and tracked against the appropriate Case records.

Data Warehouse: For long-term historical reporting and cross-functional analytics, Salesforce must push its transactional data to the enterprise Data Warehouse. This ensures the Analytics and Business Intelligence Tool can continue to provide a holistic view of company performance.

By selecting Option C, the architect recognizes that Salesforce replaces the legacy case management function while requiring strategic integration with the Data Warehouse, Order Management, and Email Management systems to achieve a true 360-degree view of the customer.

To provide "instant access" for new customers via an external IAM system using SAML, Salesforce provides a declarative feature called Just-in-Time (JIT) provisioning.

When a customer attempts to log in to the Community (Experience Cloud) through the IAM system, the IAM system (acting as the Identity Provider) sends a SAML assertion to Salesforce. If JIT provisioning is enabled, Salesforce parses the user information contained in that assertion—such as name, email, and federation ID. If a corresponding User record does not exist, Salesforce automatically creates one on-the-fly and then logs the user in. This eliminates the need for a manual registration step or pre-provisioning accounts.

Option A is slightly incorrect because Registration Handlers are specifically associated with Authentication Providers (which use OpenID Connect/OAuth), not SAML SSO. Option C is incorrect because JIT provisioning is a feature of SAML, while Authentication Providers use the Registration Handler class to achieve the same result. For a "self-service" scenario where speed to market and standard protocols are key, SAML SSO with JIT provisioning is the architect's primary choice for automating user management and providing a seamless single-entry point for subscribers.

To meet a requirement for real-time event capture that supports an external analytics system, the arc14hitect must choose a pattern that is scalable, decoupled, and reliable. Platform Events are the modern standard for this use case.

By using a Case Trigger to publish a specific Platform Event, NTO creates a highly decoupled Publish/Subscribe architecture. The external analytics system (or a middleware layer feeding it) acts as a subscriber to the event channel. This is superior to standard callouts or outbound messaging for several reasons:

Durability: Platform Events offer a 72-hour retention window. If the analytics system is momentarily offline, it can use the Replay ID to retrieve missed events.

Atomic Transactions: Triggers can be configured to publish events only after the database transaction successfully commits ("Publish After Commit"), ensuring the analytics system doesn't receive data for transactions that were eventually rolled back.

Event Volume: Platform Events are designed to handle much higher volumes of real-time messages than standard synchronous callouts.

Option A (Apex Callouts) is a point-to-point, synchronous pattern that would block Case processing and risk hitting "Concurrent Long-Running Request" limits. Option B (Outbound Messaging) is reliable but is limited to a single object per message and uses a rigid SOAP format that is less flexible for ad-hoc external analytics than the modern JSON/CometD/gRPC structures used by the event bus. By implementing Option C, the architect ensures that every specific business milestone (refund, exchange, cancellation) is broadcasted immediately, providing the customer service director with the accurate, real-time visibility required for trending and metrics.

When a custom mobile application already secured with OAuth needs to update a record in Salesforce, the standard architectural recommendation is to use the REST API. The REST API is optimized for mobile environments because it uses lightweight JSON payloads and follows standard HTTP methods (such as PATCH for updates), which are highly compatible with mobile development frameworks.

In this specific scenario, the architect must address the Field-Level Security (FLS) constraint. Because the geolocation field is set to read-only for users, a standard UI-based update would typically fail. However, when using an inbound REST API call with a properly authorized integration user or via a "System Mode" context (if utilizing a custom Apex REST resource), the system can be configured to bypass UI-level restrictions while maintaining data integrity.

The mobile device captures the coordinates via the device's native GPS capabilities and initiates an inbound call to the Salesforce REST endpoint. Option A (Apex inbound call) is a subset of REST functionality but is only necessary if complex server-side logic is required that the standard REST API cannot handle. Option C is technically incorrect as mobile devices do not typically "receive" callouts from Salesforce in this pattern; they initiate the requests. By leveraging the standard REST API, the architect ensures a scalable, secure, and standardized integration that adheres to Salesforce's mobile-first integration principles.

In this architectural scenario, the Integration Architect must navigate two critical technical "bottlenecks": the 9-second API Gateway timeout and the 90-second backend processing time. Since the backend takes significantly longer than the gateway allows for a synchronous connection, a standard Request-Reply pattern will fail. Furthermore, having 3,000 concurrent agents perform synchronous callouts would risk hitting Salesforce's concurrent long-running request limits.

The most scalable and user-friendly solution is to implement an Asynchronous Request-Reply pattern using Platform Events and the empAPI.

When an agent clicks "Check Eligibility," Salesforce sends an initial asynchronous request to the ESB (MuleSoft). The ESB immediately acknowledges receipt with a 202 Accepted status, freeing up the Salesforce UI thread and avoiding the API Gateway’s 9-second timeout. Once the backend eligibility system completes its 90-second process, MuleSoft acts as a client to Salesforce, performing a Remote Call-In to publish a specific Platform Event containing the result and the original Request ID.

On the frontend, the Lightning UI uses the empAPI (Enterprise Messaging Platform API) to subscribe to the streaming channel for that Platform Event. Because the empAPI uses CometD technology to maintain a single long-lived connection, it can efficiently push the response to the agent's screen the moment it arrives, without requiring the agent to manually refresh or click a "Check Update" button (as suggested in Option B). This provides a "real-time" feel despite the long backend latency.

Option A is non-viable because synchronous polling would exacerbate the load on the API Gateway and likely lead to governance limit issues within Salesforce. By using Platform Events and empAPI, the architect ensures the solution remains within Salesforce's execution limits while providing a seamless, automated experience for a high-volume call center environment.

In this scenario, Salesforce acts as the trigger for a business process that completes in an external system. The architect's recommendation for the remote system to subscribe to a platform event is the classic implementation of the Remote Process Invocation—Fire and Forget pattern.1

In a Fire and Forget pattern, Salesforce initiates a process by publishing a message (the event) to the event bus and then immediately continues its own2 processing without waiting for a functional response from the target system. The "Fire" part occurs when the order details are captured and the event is published; the "Forget" part refers to Salesforce handing off the responsibility of order creation to the remote system. This pattern is ideal for improving user experience and system performance, as it avoids blocking the user interface while waiting for potentially slow back-office systems to respond.

Option A (Request and Reply) is incorrect because that would require Salesforce to make a synchronous call and wait for the remote system to confirm the order was created before allowing the user to proceed. Option C (Remote Call-In) is the inverse of what is described; it would involve the remote system actively reaching into Salesforce to "pull" the data, whereas here Salesforce is "pushing" the notification via an event stream. By using Platform Events to facilitate this hand-off, Northern Trail Outfitters ensures a decoupled, scalable architecture where the remote system can process orders at its own pace while Salesforce remains responsive to sales users.

When an organization must interact with multiple external services (34 different shipping providers) that change frequently, the primary architectural goal is to decouple Salesforce from the specific endpoints and protocols of those services.11

The architect should propose us12ing middleware to abstract the call. By introducing a middleware layer (such as an ESB or iPaaS), Salesforce makes a single, standardized call to the middleware, passing the country and order details. The middleware then handles the "Process Orchestration":

Service Routing: Determining which shipping service is valid for the specified country.

Protocol Mediation: Translating the standard Salesforce request into the specific format (REST, SOAP, XML, etc.) required by each individual shipping provider.

Maintenance: When a shipper is added or removed, the change is made in the middleware without requiring any code or metadata updates in Salesforce.

Option A (Picklists) creates a high administrative burden and does not solve the underlying technical complexity of making callouts to dozens of different APIs. Option B (Platform Events) is asynchronous and would introduce unnecessary latency for a sales rep who needs an estimate "on the spot" to complete an order. Middleware abstraction provides a scalable, maintainable, and agile architecture that allows NTO to optimize its shipping operations without disrupting the CRM user experience.