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

When optimizing REST API consumption, an Integration Architect must select the specific composite resource that maximizes record throughput per request. While the Salesforce REST API offers several "Composite" resources to group multiple operations, they have vastly different payload limits.

The sObject Tree resource (`/services/data/vXX.X/composite/tree/`) is uniquely designed to handle up to 200 records in a single post request. Although its primary architectural purpose is to create complex nested hierarchies (parent-to-child relationships) in one transaction, it can also be used to send a flat list of up to 200 records of the same type. This directly satisfies the requirement to increase bulk capability within the REST framework.

In contrast, the Batch and Composite resources have much more restrictive limits. The Composite resource allows you to execute a series of up to 25 subrequests in a single call. While these subrequests can be linked, the total number of records processed is significantly lower than the sObject Tree's 200-record threshold. Similarly, the Batch resource also limits the caller to 25 subrequests, where each subrequest is an independent REST API call executed in a single batch.

By implementing the sObject Tree resource, the architect achieves a 200:1 reduction in API call consumption for these updates. This approach respects the customer’s constraint to avoid major "architecture changes"—such as switching to the Bulk API 2.0 or introducing middleware—while effectively resolving the issue of exceeding daily governor limits. It is a highly efficient way to handle medium-volume data synchronization within the standard RESTful interface.

---

The foundational step in a CRM transformation project is to understand the business context and data landscape before selecting technical tools or middleware.

Before proposing a technical solution, an architect must evaluate current and future data and system usage to identify specific integration requirements. This includes documenting business processes, mapping data flows between the Marketing system, Outlook, and the ERP, and identifying which system will serve as the "System of Record" for each data entity. For example, the architect needs to determine if lead data from the Marketing system should flow unidirectionally to Salesforce or if activities from Outlook need bidirectional synchronization to maintain a "360-degree view".

While out-of-the-box connectors (Option B) and middleware (Option C) are valuable, they are implementation tactics that follow the discovery phase. Jumping directly to connectors may overlook unique business processes that require custom integration logic, while proposing middleware prematurely can lead to unnecessary costs if native tools or point-to-point connections are sufficient. A thorough evaluation ensures that the integration architecture is scalable, avoids data corruption, and aligns with UC's strategic goal of breaking down information silos to provide sales and support staff with meaningful, unified customer insights.

Resiliency in long-running Batch Apex processes is best achieved by utilizing modern, event-driven error handling frameworks provided by the Salesforce platform. The BatchApexErrorEvent is the architecturally recommended component for monitoring and responding to failures in Batch Apex jobs.

When a Batch Apex class implements the `Database.RaisesPlatformEvents` interface, the platform automatically publishes a BatchApexErrorEvent whenever an unhandled exception occurs during the execution of a batch. This event contains critical metadata, including the exception message, the stack trace, and the scope (the specific IDs of the records that were being processed when the failure occurred).

An Integration Architect should recommend building a Platform Event Trigger that subscribes to these error events. This trigger can perform sophisticated error handling logic, such as:

* Logging the failure details into a custom "Integration Error" object for auditing.

* Initiating a retry logic by re-enqueuing only the failed records into a new batch job.

* Notifying administrators or external systems via an outbound call or email.

This approach is superior to Option B (internal handling) because unhandled exceptions often cause the entire batch transaction to roll back, potentially losing any error logging performed within the same scope. It is also more efficient than Option C (middleware), as it keeps the error recovery logic "close to the data," reducing the need for external systems to constantly poll for job status or parse complex logs. By using BatchApexErrorEvent, UC ensures a resilient, self-healing process that maintains the integrity of the invoice generation cycle.

---

In a contract-first integration approach using RAML, the specification acts as the single source of truth for request and response structures. Since Salesforce unit tests are prohibited from performing actual network callouts, the HttpCalloutMock interface must be used to simulate external API behavior.

To ensure unit tests truly confirm adherence to the RAML contract, the architect must mandate that the mock implementation specifically returns responses formatted per the RAML specification. This means the mock's JSON or XML body, headers, and HTTP status codes (e.g., 200 OK, 400 Bad Request) must exactly match the "interface contract" defined in the RAML file.

By strictly aligning the mock with the RAML spec, developers ensure that the Apex client's parsing logic (e.g., JSON.deserialize()) is tested against the agreed-upon data model. If the external service later changes its schema in a way that deviates from the RAML, the unit tests—which are based on that contract—will help identify where the Apex code might fail. Options B and C are technically incorrect: the client does not "call" or "implement" the mock; rather, the test runtime provides the mock instance to the client via Test.setMock().

When integrating with a legacy SOAP-only application using a Fire and Forget pattern, Salesforce Outbound Messaging is the native, declarative choice.

Outbound Messaging is a platform feature that sends a SOAP message to a designated endpoint when specific criteria are met. It is inherently asynchronous and provides built-in reliability; if the legacy system is offline, Salesforce will automatically retry the delivery for up to 24 hours. This perfectly fits the "Fire and Forget" requirement.

For the strongly-typed response back (Remote Call-In), the Enterprise WSDL is the correct recommendation.1415

Enterprise WSDL: This is a strongly-typed WSDL generated specifically for one org's metadata. It includes specific references to16 custom objects and fields, ensu17ring that the legacy system can communicate with Salesforce using a rigid, predictable data structure.

Partner WSDL (Option C): This is a loosely-typed WSDL designed for developers building tools that must work across many different orgs; it is not ideal for an internal, strongly-typed legacy integration.

While Platform Events (Option B) are a modern alternative, they typically use REST or Streaming APIs, making them a less natural fit for an application that "can only support SOAP". By combining Outbound Messaging and the Enterprise WSDL, the architect provides a robust, SOAP-native solution that satisfies the business's technical constraints and reliability requirements.

To securely integrate a distributed package with a central "Hub" org, the architect should utilize the OAuth 2.0 Web Server Flow. In this model, a Connected App is created in the central org to act as the identity and access provider.1

A critical component of this setup is the Callback URL (Redirect URI). When a user in the "Subscriber" org (where the packag2e is installed) initiates the connection, Salesforce redirects them to the central org to authorize the access. After successful authentication, the central org needs the correct callback URL to return the authorization code to the specific subscriber org.

Using this flow satisfies the security team's requirement for a specific integration account. The administrator in the central org can pre-authorize specific profiles or permission sets to use the Connected App, ensuring that only the designated integration user's credentials are used to fulfill requests. Option A is a security "anti-pattern" (storing passwords in fields), and Option C is unnecessary as API access is a standard feature. This OAuth-based approach provides a secure, revocable, and standardized way to manage cross-org communication in a multi-tenant environment.

When building custom mobile or web applications that aim to replicate the look and feel of Salesforce Lightning Experience, the User Interface (UI) API is the architecturally recommended choice.

The UI API is specifically designed to provide the metadata and data needed to build high-fidelity user interfaces. Unlike the standard REST API (Option B), which returns raw record data, the UI API returns both data and metadata in a single response. This includes information about page layouts, field-level security, picklist values, and localized labels. By using the UI API, the mobile app can dynamically render fields according to the user's permissions and the organization's layout configurations, ensuring that the custom app stays in sync with changes made in Salesforce Setup without requiring code updates in the mobile app.

Connect REST API (Option A) is primarily used for Chatter, Communities (Experience Cloud), and CMS content, and while it is useful for those specific social features, it does not provide the layout and record-level metadata required for a full CRM interface. The UI API is the same underlying technology that powers the Salesforce mobile app and Lightning Experience itself. Therefore, utilizing this API allows NTO's developers to build a native app that perfectly mimics the Lightning Experience while reducing the amount of custom logic needed to handle complex Salesforce UI requirements.

For organizations using both Salesforce Service Cloud and B2C Commerce (formerly Demandware), Salesforce provides a specialized, pre-built integrat25ion known as the Salesforce B2C Commerce to Service Cloud Connector. This connector is part of the Salesforce B2C Solution Architecture and is the recommended choice because it offers "out-of-the-box" cross-cloud functionality.

The connector enables several critical business processes for service agents:

Unified Customer Profile: Synchronizes customer data between the two platforms, ensuring agents have the most current contact information.

Order History Visibility: Allows agents to view real-time order data and status from the Commerce system directly within the Service Console.

Service Actions: Enables agents to perform commerce-related tasks, such as "Order on Behalf Of," without leaving the Salesforce interface.

While an architect could build a custom integration using the Commerce REST API (Option A) or MuleSoft (Option C), these approaches require significant development, testing, and long-term maintenance effort. The B2C Connector reduces time-to-market and leverages Salesforce's own engineering to handle complex synchronization logic and API versioning. Recommending the standard connector aligns with the architectural principle of "clicks before code" and ensures that the integration remains supported by Salesforce as both platforms evolve.

To satisfy a requirement for near real-time REST updates with limited development resources, the architect should utilize Flow Builder. Flow Builder is Salesforce's primary low-code tool for automating complex business logic and outbound integrations.

The Remote Process Invocation—Fire and Forget pattern is the most efficient way to signal an external system (or middleware) that a record was created without blocking the user. Using a Record-Triggered Flow on the Order object, the architect can configure an Action (such as an External Service or a simple HTTP Callout) to send the order data to the middleware's REST endpoint.

Option A is slightly incorrect because creating a platform event is just one step in an event-driven flow; the "Fire and Forget" pattern more accurately describes the end-to-end intent. Option B (Change Data Capture) is a powerful tool, but it is considered a "pro-code" or high-configuration so12lution on the middleware side, requiring the middleware to manage Replay IDs and Bayeux subscriptions. Option C leverages the native strengths of Flow to fulfill the requirement declaratively, 13allowing the team to14 deliver a functional integration without writing Apex code while meeting the near-real-time performance expectations of the ERP.