Configure named credentials in the source org.

Call the Salesforce REST API to insert the lead into the target system.

Explanation

Two Salesforce orgs are merging; the old org stays active briefly for web-to-lead forms. New leads must appear in the new org within 30 minutes using minimal development. The solution should leverage out-of-box or low-code tools for real-time or near real-time sync without complex custom code or middleware.

✅ Correct Option: A. Configure named credentials in the source org
Named Credentials simplify secure callouts by bundling endpoint URL + auth (e.g., OAuth).
Set once in source org → reusable in Flow/Apex/Process Builder.
Zero code for auth management — reduces dev effort and maintenance.
Essential foundation for any REST-based sync (pairs perfectly with option D or B).

✅ Correct Option: D. Call the Salesforce REST API to insert the lead into the target system
Use REST API (/services/data/vXX.X/sobjects/Lead) from a Flow or Process Builder trigger on Lead insert.
Declarative callout via Flow’s “Apex Action” or “HTTP Callout” (with Named Credential).
Inserts lead instantly (<1 min) — well under 30-min SLA.
No scheduled jobs or batch code — pure low-code automation.

❌ Incorrect Option: B. Use the Composite REST API to aggregate multiple leads
Composite API batches up to 25 records — useful for volume, but not needed here.
Requires collecting leads first (custom staging or delay) → breaks real-time flow.
Adds complexity (parsing responses, error handling per record) → more dev effort, not less.

❌ Incorrect Option: C. Use the Tooling API with Process Builder
Tooling API is for metadata ops (e.g., creating fields), not record DML.
Cannot insert Leads — completely wrong API.
Even if misused via REST, it’s unsupported, complex, and high-effort — anti-pattern.

📚 Reference
Named Credentials
Flow HTTP Callout (Beta)
Introduction to REST API

ERP, MDM, Data Warehouse, Invoices system

Explanation:

The architect must identify all external systems that must exchange data with Salesforce Sales Cloud to fulfill the stated business requirements. This involves integrating systems of record for master data (customers/prospects), transactional data (inventory, pricing, invoices), and reporting data (sales dashboards). The goal is to ensure all essential data is available where and when it's needed within the sales process, either by bringing it into Salesforce or providing a path to send Salesforce data out.

Correct Option: ✅

D. ERP, MDM, Data Warehouse, Invoices system

ERP (Enterprise Resource Planning):
Needed for inventory, pricing (Source of Truth), and order generation/fulfillment data (as a system of record for pricing).
MDM (Master Data Management):
Required as the system of record for customers and prospects (Requirement 5). This master data must be synchronized with Salesforce to ensure accurate account and contact information.
Data Warehouse (Implied by BI Tool):
The Enterprise Business Intelligence (BI) tool (Requirement 4) typically consumes data from a Data Warehouse. Salesforce sales data must be sent to the Data Warehouse for consolidation and reporting via the BI tool, making the Data Warehouse a mandatory integration point.
Invoices system:
Required to make invoices accessible in Salesforce (Requirement 6), necessitating a direct or indirect integration to retrieve or view invoice records.

Incorrect Option: ❌

A. ERP, Invoices system, Data Warehouse and BI Tool
This option misses the crucial MDM system, which is explicitly stated as the system of record for customer/prospect data (Requirement 5). Integrating the BI Tool directly is often done via the Data Warehouse, and the primary data flow is from Salesforce to the data warehouse, not a direct integration between Salesforce and the BI tool itself.

B. ERP, Inventory, Pricing Engine, Invoices system
This option incorrectly lists Inventory and Pricing Engine as separate systems. The requirements state that ERP is the system of record for pricing and sales needs access to current inventory. Therefore, both pricing and inventory data integration are likely handled by integrating with the ERP system itself, not separate systems named Inventory or Pricing Engine, while still missing the critical MDM and Data Warehouse systems.

C. ERP, MDM, BI tool and Data Warehouse
This option misses the Invoices system (Requirement 6). While including the BI tool is technically part of the reporting flow, integrating with the Data Warehouse is the architectural step that facilitates the BI tool's dashboard views, and the absence of the explicit Invoices system makes this incomplete.

Reference:
Salesforce Integration Architecture Design
“A robust integration architecture requires identifying all systems of record for master data (like Customer/MDM) and transactional data (like ERP/Invoicing) that must participate in the end-to-end business process. Reporting needs (BI/Data Warehouse) also dictate necessary data integration flows.”
System Landscape
Integration Patterns

Source and Target system, Directionality, data volume & transformation complexity long with any middleware that can be leveraged.

Timing aspects - real-time/near real-time (synchronous or asynchronous), batch; update frequency.

Integration Style Process based, Data based, Virtual integration. E Core functional and non functional requirements for User Experience design, Encryption needs, Community, and license choices.

Explanation

To design a reliable integration architecture, a Salesforce Integration Architect must fully understand how data moves between systems, how often it moves, and how deeply the systems depend on each other. This requires clarity around system endpoints, integration direction, volumes, timing expectations, and the integration style. These details directly influence tool choice, scalability needs, performance behavior, and the architectural approach. Options A, C, and D align precisely with these technical integration considerations.

✔️ Correct Options

A. Source and Target system, Directionality, data volume & transformation complexity along with any middleware that can be leveraged.
This option captures foundational technical elements required in integration design. Knowing the source and target systems sets the architecture scope. Understanding directionality and data volume influences throughput and integration patterns. Transformation complexity determines whether middleware is needed and what tools fit the architecture. These details directly impact performance, mapping, latency, and overall feasibility, making them essential for integration planning.

C. Timing aspects - real-time/near real-time (synchronous or asynchronous), batch; update frequency.
Integration timing defines how data is exchanged and which integration pattern is appropriate. Real-time and near-real-time use synchronous or asynchronous APIs, while batch updates require scheduled jobs or ETL processes. The update frequency affects API limits, processing windows, and scalability needs. Without understanding timing expectations, the architect cannot decide the correct mechanism or prevent performance bottlenecks.

D. Integration Style – Process-based, Data-based, Virtual integration.
Knowing which integration style the business process requires is crucial. Process-based integrations drive user or system workflows across platforms. Data-based integrations focus on synchronization across systems. Virtual integrations expose data without storing it. These styles guide the selection of technologies such as APIs, platform events, data virtualization, or ETL, and form the core of integration architecture decisions.

❌ Incorrect Options

B. Integration skills, SME availability and Program Governance details.
While important for project planning and resourcing, these factors do not directly determine the technical integration architecture. They help manage delivery but do not influence system design choices such as integration patterns, data flows, timing, or system constraints. Therefore, they are not part of the key architectural information needed for designing integrations.

E. Core functional and non-functional requirements for User Experience design, Encryption needs, Community, and license choices.
This option includes broader program considerations such as UX, encryption, licensing, and community setup, which are important but not specific to integration architecture needs. Encryption may relate to integration security, but the rest of the items focus on application design, licensing, and user experience—not integration flow, timing, or integration style.

Reference
Integration Patterns

Include selective criteria in query filters.

Remove the sharing restrictions.

Explanation

This scenario involves optimizing a high-volume data integration that processes millions of contacts daily. The current implementation suffers from performance bottlenecks due to inefficient query design and unnecessary sharing calculations. The solution must address both data filtering efficiency and system-level access requirements for bulk operations.

✔️ Correct Options

(C) ✅ Include selective criteria in query filters:
Selective queries use indexed fields to efficiently narrow results, which is critical for large data volumes. Non-selective filters force full table scans that timeout with millions of records. Creating queries that leverage indexed fields (like custom flags or date ranges) dramatically improves performance by reducing the dataset size before processing.

(D) ✅ Remove the sharing restrictions:
Sharing hierarchy calculations add significant overhead by enforcing user-specific data visibility for each record. For system-level integrations that need access to all records, these restrictions create unnecessary performance bottlenecks. Running the integration without sharing or using system context eliminates this computational burden.

❌ Incorrect Options

(A) Include non-selective criteria in query filters:
This approach would severely degrade performance by forcing the query to scan every contact record. Non-selective criteria (like non-indexed fields or overly broad filters) are the primary cause of timeout errors in large-volume integrations and should be avoided.

(B) Remove the query filters:
Removing filters entirely would be catastrophic for performance, causing the integration to attempt processing all millions of contacts without any data reduction. This would guarantee governor limit exceptions and complete integration failure.

📚 Reference
Salesforce's official documentation on "Query & Search Optimization" emphasizes using selective queries with indexed fields to avoid performance issues. The "Apex Developer Guide" specifically recommends running bulk operations without sharing to bypass costly sharing calculations for system-level integrations.

Use External Services feature to integrate gateway to Salesforce ensuring realtimeupdates the CSR and support post payment processes.

Explanation

A CSR must submit credit card details via Salesforce to an external REST payment gateway, wait for confirmation, then upgrade the service. The integration demands real-time response, reliable callouts, and audit logging. It’s a synchronous, user-driven flow requiring immediate feedback before proceeding — all within Lightning UI for the CSR.

✅ Correct Option: B. Use External Services feature
External Services lets you register the payment gateway’s OpenAPI schema and generate Apex actions for callouts — no hand-coded HTTP.
Callouts are synchronous, so CSR gets real-time success/failure before upgrading.
Request/response payloads are auto-logged in Setup → External Service Calls for audit.
Supports Flow/Lightning actions — perfect for CSR screen flow with wait-for-confirmation.

❌ Incorrect Option: A. Custom Apex Callout
Building manual HttpRequest/HttpResponse works but requires custom logging (e.g., Platform Events, Custom Objects).
Higher dev effort; no built-in audit trail unless explicitly coded.
Risk of governor limit issues and maintenance overhead — External Services is the declarative alternative.

❌ Incorrect Option: C. Callout through ESB
An ESB (Enterprise Service Bus) adds middleware — unnecessary complexity for a simple REST callout.
Introduces latency, extra cost, and single point of failure.
CSR needs direct real-time response — ESB is overkill and breaks synchronous flow.

❌ Incorrect Option: D. Platform Events
Platform Events are asynchronous and event-driven — CSR cannot wait for payment confirmation.
No native support for calling external REST APIs; requires triggers + callouts (complex).
Designed for decoupled publishing, not request-response with user wait time.

📚 Reference
Salesforce Help – External Services
External Services Call Logs