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

When designing an event-driven architecture to track order processing stages (Created, Shipped, Paid), the Integration Architect must ensure the solution provides "durability"—the ability to recover messages that were sent while a subscriber was offline or during a system failure. In Salesforce, this is managed through the Event Bus and the ReplayID mechanism.

For High-Volume Platform Events and Change Data Capture, Salesforce provides a standard retention window of 72 hours (3 days). This means that events are stored in the bus for this duration, allowing clients to "replay" events that occurred in the past. To leverage this durability, the subscribing client must specify where in the event stream they wish to begin receiving messages.

There are two special values for the ReplayID:

ReplayID = -1 (Tip of the Stream): The subscriber receives only new events that are published after the subscription is established. Any events published while the client was disconnected are missed. This does not meet the requirement of seeing processing stages that occurred within the retention window if the connection was interrupted.

ReplayID = -2 (All Available Events): The subscriber receives all events that are currently stored in the event bus (up to 72 hours old) as well as all new events.

By recommending the use of ReplayID = -2, the architect ensures that even if the Salesforce frontend or the integration middleware experiences downtime, the system can "catch up" by retrieving all order status updates (Shipped, Paid, etc.) that were published during that window. This provides a robust and resilient user experience, ensuring that the Opportunity and Order records in Salesforce accurately reflect the state of the ERP system without data gaps. This configuration is essential for maintaining data synchronization in a distributed landscape where Salesforce acts as the engagement layer for a back-1end ERP master.

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.

When dealing with multiple external service providers (like different regional shippers) that have varying API requirements, the most scalable architectural choice is an Enterprise Service Bus (ESB) or middleware solution. This scenario describes a classic "Orchestration" and "Transformation" use case.

An ESB excels at:

1. Routing/Mediation: The ESB can receive a single, standardized request from Salesforce ("Get Shipping Rates") and use business logic to determine which regional carrier's API should be called.

2. Transformation: Each carrier likely has a distinct XML or JSON schema. The ESB can transform the common data model sent by Salesforce into the specific format required by the chosen shipper.

3. Protocol Bridging: If one shipper uses SOAP and another uses REST, the ESB handles these technical differences, allowing Salesforce to interact with a single, simplified interface.

Option A (Apex REST) would require the Salesforce team to maintain custom code for every new shipping provider added, leading to high technical debt and maintenance challenges. Option C is incorrect because an ESB is a back-end infrastructure component, not a user interface tool.

By utilizing an ESB, Northern Trail Outfitters decouples Salesforce from the complexities of the shipping providers' APIs. This "Hub and Spoke" model means that adding a new regional shipper in the future only requires configuration within the ESB, rather than a full code deployment in Salesforce. This provides the agility and architectural separation necessary for a global retail operation.

When an integration initiated from the client-side (the browser) fails, the architect must first look at the browser's security policies. In Salesforce, Lightning Web Components are subject to the Lightning Component framework's Content Security Policy (CSP).

CSP is a security layer that prevents cross-site scripting (XSS) and other code injection attacks by restricting which domains the browser is allowed to communicate with. If an LWC attempts to make a fetch() call to an external REST endpoint, the browser will block the request unless that specific domain is whitelisted in CSP Trusted Sites.

Option B (Remote Site Settings) is a common distractor; these settings are strictly for server-side Apex callouts and have no effect on client-side JavaScript requests. Option A (CORS) is also a browser security mechanism, but it must be configured on the external server to allow Salesforce to access its resources. While CORS is necessary, the first thing to validate within the Salesforce environment for a failing LWC callout is the CSP Trusted Site entry. Without this whitelisting, the request will be terminated by the browser before it even leaves the client, regardless of how the external server is configured.

Prior to implementing Shield Platform Encryption, the most critical step for an Integration Architect is to perform a comprehensive Review of Shield Platform Encryption configurations and their impact on existing platform functionality. Encryption at rest is not a "set-and-forget" feature; it changes how the Salesforce database interacts with various features, and failing to review these limitations beforehand can lead to significant business disruption.

Salesforce documentation emphasizes that encryption affects several core areas:

SOQL/SOSL Limitations: Encrypted fields have restricted capabilities in WHERE, GROUP BY, and ORDER BY clauses.1 For example, if Social Security Numbers (SSNs) are encrypted using Probabilistic Encryption, they cannot be filtered or sorted in a query.2 This could break existing integrations or reports that rely on finding specific records by SSN.

Search Functionality: While Salesforce supports searching for encrypted data, there are specific behaviors to consider regarding how search indexes are built and updated.

AppExchange and Managed Packages: If the SSN field is used by a third-party app or a managed package, encrypting it might cause those external tools to fail if they are not designed to handle encrypted data types.

Field Attributes: Encrypted fields cannot be used as Unique or External IDs if using the probabilistic scheme, which is a vital consideration for data synchronization architectures.3

Therefore, the architect must first conduct a Business Impact Analysis. This includes identifying where the sensitive data (SSNs) is used in Apex code, Flows, validation rules, and reports. By reviewing the configurations and functional limitations first, the architect can decide between Probabilistic (higher security) and Deterministic (allows filtering) encryption strategies.4 Option A is a step taken during or after implementation (Background Encryption), and Option C is an anti-pattern, as encrypting "everything" leads to unnecessary performance overhead and massive functional loss. Only after a thorough review can the architect safely proceed with the technical implementation of Shield.

The primary architectural flaw in UC's current landscape is the reliance on a monolithic P2P integration layer. In such designs, any failure in one integration thread or a surge in volume for one system can monopolize resources (CPU, memory, threads), causing the entire service—and thus all other integrations—to fail. This lack of isolation leads to the "tight interdependencies" described.

To effectively decouple these systems, the architect should recommend a Microservices Architecture. By breaking the monolithic service into smaller, independent, and modular components, each integration (Billing, ERP, Data Lake) becomes its own isolated service. This approach provides several key architectural benefits:

Isolation of Failure: If the connection to the legacy billing application fails or times out, it no longer impacts the ERP or Data Lake integrations.

Independent Scalability: If the Data Lake integration requires high throughput, that specific microservice can be scaled horizontally without wasting resources on the others.

Technology Agility: Each microservice can be updated or patched independently, allowing for faster maintenance cycles.

Furthermore, moving a "monolithic" service to the cloud (Option B) is simply a "lift and shift" that preserves the underlying fragility. While the Bulk API (Option A) is excellent for high-volume data loading, it does not solve the fundamental problem of system interdependency and orchestration failure. Transitioning to a modular, service-oriented design allows UC to implement modern integration patterns, such as asynchronous queuing between the microservices, which significantly improves the overall resilience and performance of the Salesforce-to-back-office landscape.

In a complex landscape where multiple systems contain overlapping customer data, each with its own primary key, the core architectural challenge is Identity Management. To ensure that an update in Salesforce (the System of Record) correctly updates "Customer A" in the ERP and "Customer A" in the Data Lake, a Master Data Management (MDM) strategy is required.

An MDM solution creates a Cross-Reference (X-Ref) Table or a "Golden Record" that maps the unique identifiers from all systems. In the Salesforce record, the architect should implement External ID fields for each corresponding system (e.g., ERP_ID__c, Ticket_System_ID__c).

Why this is the superior recommendation:

Bidirectional Integrity: When the middleware receives an update from the ERP, it uses the ERP_ID__c to perform an "upsert" in Salesforce, ensuring no duplicates are created.

Traceability: It allows for easy auditing of data lineage across the enterprise.

Decoupling: Salesforce doesn't need to know the internal logic of the ERP; it simply holds the reference key.

Option B (CDC) is a delivery mechanism, not an identity management strategy; it tells you that something changed, but not which record in the ERP it corresponds to without the ID mapping. Option C (Local caching in middleware) is an "anti-pattern" because it makes the middleware stateful; if the middleware cache is lost or out of sync, the entire integration breaks. By designing an MDM-based mapping solution directly within the data model, the architect ensures a robust, scalable, and transparent identity framework for the entire enterprise.

Securing an outbound integration from Salesforce to an external system like Microsoft Azure requires ensuring that the external endpoint can trust the requests coming from Salesforce. One of the most robust methods for securing this communication at the transport layer is Mutual Authentication (Two-Way SSL/TLS).

In a standard SSL handshake, the client verifies the server’s certificate. In Mutual Authentication, the server (in this case, the Azure API Gateway) also requests and validates a certificate from the client (Salesforce). This ensures that only authorized clients can even establish a connection. For production environments, Salesforce architects recommend using certificates signed by a Certification Authority (CA) rather than self-signed certificates to ensure a chain of trust that is recognized globally.

Option C is a common point of confusion; while Connected Apps and OAuth are essential for securing inbound requests into Salesforce, they do not natively secure the connection when Salesforce is acting as the client calling an external gateway. Option A focuses on user-level access within Salesforce but does not address the point-to-point security between the two platforms. By implementing Two-Way SSL, Northern Trail Outfitters ensures that the Azure API Gateway identifies Salesforce as a trusted source before any data is exchanged, providing a high level of security that protects against "Man-in-the-Middle" attacks and unauthorized access attempts.

Governance and maintenance are critical when using event-driven architectures. Unlike standard objects, which can often be retrieved from the Recycle Bin, Platform Event definitions are handled with high permanence. Once an event definition is deleted, it is permanently removed. This deletion also immediately destroys any associated triggers, subscriptions, and any events currently stored in the event bus. Architects must highlight this risk to ensure proper metadata backup and change management processes are in place. Options A and B refer to specific security and monitoring features that are secondary to the fundamental architectural risk of permanent metadata loss.