Can the fulfillment system make a callback into Salesforce?

Is the product catalog data identical at all times in both systems?

Explanation:

Callbacks into Salesforce are critical if you plan to use asynchronous communication patterns like Outbound Messaging or Platform Events that require acknowledgment or updates. Meanwhile, ensuring product catalog consistency is essential for order accuracy. If catalogs are misaligned, users might create orders with invalid or outdated items. Questions about address creation and contract-first design are more implementation details and less about initial architectural feasibility.

Change Data Capture does not have record access support.

Explanation:

The architect should note that:

→ CDC Limitations: Change Data Capture (B) doesn't support filtering by record access permissions (unlike PushTopics).
→ Platform Events (Not Listed): Would be better for custom event publishing.

PushTopics (A) allow query-based payloads but are legacy. The correct guidance depends on whether row-level security is needed for the streaming data.

Smaller batch size may increase time required to execute bulk jobs.

Smaller batch size can trigger "Too many concurrent batches" error.

Explanation:

When using Salesforce Bulk API, large batch sizes can exceed CPU limits during processing—especially if triggers, flows, or validation rules are intensive. Reducing the batch size is a logical mitigation step, as smaller chunks reduce CPU time per execution unit. However, this increases the number of batches needed to complete the job.

More batches mean longer total execution time (B), since each batch must be queued, processed, and possibly retried. Additionally, Salesforce imposes limits on concurrent batches—typically 5 for synchronous and up to 100 for asynchronous jobs depending on org limits. Exceeding this results in “Too many concurrent batches” errors (D), halting or delaying processing.

While it’s tempting to reduce batch sizes drastically, it’s important to balance performance and limit thresholds. Options A and C are incorrect: smaller batch sizes reduce locking issues, and they don’t inherently violate concurrent API request limits, which are separate from batch execution concurrency.

The middleware solution is capable of establishing a secure API gateway between cloud applications and on-premise resources.

An API gateway component is deployable behind a Demilitarized Zone (DMZ) or perimeter network.

Explanation:

When integrating Salesforce (a cloud platform) with on-premise resources, the architect must overcome challenges like firewall restrictions, network security, and data governance. Middleware becomes a bridge, often deployed in a DMZ to allow limited, controlled access from external systems while maintaining a strong internal security posture.

A key requirement is that the middleware can act as a secure API gateway (A)—this enables controlled exposure of internal services to Salesforce or other cloud platforms. The ability to deploy components of the middleware inside the DMZ (B) is critical. It enables routing or proxying of requests while ensuring that no direct access is granted to internal systems.

Options C and D are less critical or incorrect: OAuth (C) is typically used for user authentication, not always for middleware; and direct ODBC connections (D) from Salesforce via middleware are rarely recommended due to security and scalability issues.

Partner WSDL

Explanation:

Salesforce offers two main WSDLs for SOAP integrations: Enterprise and Partner. The Enterprise WSDL is strongly typed and tightly coupled with a specific org’s metadata (custom objects, fields, etc.). This means it must be regenerated if metadata changes, and is not portable across orgs.

In contrast, the Partner WSDL is loosely typed and uses a more flexible schema. It represents objects and fields as generic name-value pairs (like sObject and fieldsToNull), which makes it ideal for cross-org integrations where metadata varies or changes frequently.

For ISVs or scenarios where the integration must be reusable across different Salesforce environments (e.g., dev, staging, production, or multiple clients), the Partner WSDL is the better choice. It’s also better suited for dynamic scenarios like schema discovery or integration with systems that don't maintain tight data models.

Thus, Partner WSDL provides maximum flexibility, making it the preferred option when metadata cannot be guaranteed to be identical across orgs.

Named Credentials

Protected Custom Metadata Types

Explanation:

Salesforce provides multiple mechanisms to store secrets securely and avoid hardcoding sensitive data like OAuth tokens, API keys, and credentials. The best practice is to use Named Credentials (B), which securely store authentication settings (e.g., username/password, OAuth tokens) and abstract them from Apex code. This ensures secrets aren't exposed in code or config and simplifies endpoint management.

Protected Custom Metadata Types (C) allow you to store config data like endpoints, keys, or feature flags. Marking metadata records as "protected" ensures they are not visible outside managed packages, shielding secrets from org admins and preventing accidental exposure.

Encrypted Custom Fields (A) are better for storing secure business data (e.g., SSNs), not integration secrets. Protected Custom Settings (D) are legacy tools and lack the security enforcement of Protected Custom Metadata—making them less safe for storing secrets.

Using Named Credentials and Protected Metadata Types ensures compliance with secure coding practices and reduces risk from accidental disclosure or misuse of sensitive integration data.

Make an API inbound integration from an external Java client more secure.

Explanation:

Salesforce supports SAML-based Single Sign-On (SSO) for both UI and API authentication. If a company already uses a SAML-compliant Identity Provider (IdP), this can be extended to secure inbound API connections. For example, a Java client integrating with Salesforce can authenticate users using SAML Bearer Assertion Flow. This allows the external system to obtain an access token for Salesforce using a previously authenticated SAML session, eliminating the need to store or transmit passwords.

Options B and C (Apex outbound calls) are not secured via SAML, as SAML is primarily for inbound user authentication—not for securing outbound REST/SOAP integrations from Salesforce.
Option A (HYPERLINK fields) isn't relevant to authentication at all.

So, option D is correct because it properly applies SAML for authenticating API requests coming into Salesforce, leveraging existing identity infrastructure and enhancing security by removing reliance on stored credentials.

Develop custom APIs on the company's network that are invokable by Salesforce.

Deploy MuleSoft to the on-premise network and design externally facing APIs to expose the data.

Explanation:

To achieve real-time data access from Salesforce to on-premise systems, the integration must overcome network barriers and ensure secure, low-latency access. Developing custom REST or SOAP APIs (B) on the internal network that Salesforce can invoke (via callouts) is a direct and flexible approach. These APIs should be exposed securely through a DMZ or API gateway.

Alternatively, MuleSoft (C) is an ideal middleware solution for hybrid integrations. When deployed on-premise, MuleSoft can bridge cloud-to-ground communication, managing authentication, transformation, and secure API exposure. It simplifies complex integration flows and allows centralized governance and error handling.

Option A (Heroku + ODBC) is overly complex and introduces unnecessary hops. Option D (batch ETL) does not support real-time use cases and contradicts the requirement for live access.

Therefore, the best strategy includes secure, API-based access with minimal latency, enabled either directly or through a robust integration platform like MuleSoft.

Users should be authorized to view information specific to the customer they are servicing without a need to search for customer.

Consider Enterprise security needs for access to DMS and EBS.

Users should be authenticated into DMS and EBS without having to enter username and password.

Explanation:

Integrating Salesforce with systems like Document Management Systems (DMS) and Enterprise Billing Systems (EBS) requires strong identity and access control. First, users should be able to view only data for the customer they are supporting (A)—this is critical for both data privacy and security compliance.

Enterprise-level security (C) must be accounted for, including firewall restrictions, audit logging, and encryption. The architecture should align with internal IT and security policies, especially when exposing sensitive customer billing and document data.

For seamless user experience, users should be authenticated into DMS and EBS without re-entering credentials (E). This is best achieved with SSO or token-based authentication (like SAML or JWT), which improves usability and security by avoiding password proliferation.

Option B (storing credentials in Salesforce) is discouraged due to security risks. Option D (migrating DMS/EBS into Salesforce) is impractical for most enterprises due to cost, complexity, and compliance limitations.

Callouts to RESTful services

Encryption in transit and at rest

Explanation:

To meet strict data privacy requirements for medical data, integrations must ensure security and compliance. The Community Cloud portal (now called Experience Cloud) must retrieve sensitive prescription data via secure RESTful APIs (C). These APIs are built to support token-based access control (e.g., JWT, one-time-use tokens) and ensure that only authorized users can access specific data.

In addition, encryption in transit and at rest (D) is a regulatory and ethical requirement. TLS/SSL ensures data is secure during transmission, while database-level or platform encryption protects stored data from unauthorized access. Einstein Analytics (now Tableau CRM) must also adhere to these policies if it handles even de-identified data.

Option A (storing identity tokens) is incorrect, as tokens are transient and should not be persisted. Option B (bulk loading into analytics) violates the real-time, secure, and minimal retention principles defined in the scenario.

Insert and query using Bulk API 2.0.

Explanation:

Salesforce Bulk API 2.0 is optimized for large-scale data operations with simplified job management and better performance over Bulk API 1.0. It automatically handles batching and concurrency behind the scenes. For inserting 90 million records in a day, Bulk API 2.0 is the best-suited tool due to its ability to parallelize jobs and manage throughput automatically.

Moreover, querying 30 million records for extraction (e.g., audit system) is also more efficient with Bulk API 2.0, which supports PK chunking and handles large result sets better than the REST API. REST API isn't built for high-volume querying—it’s better for transactional data.

Bulk API 1.0, while still valid, requires manual batch splitting and doesn’t scale as effectively. Big Objects (used in D) are for long-term storage of non-transactional data—not for high-volume daily inserts and extracts.
Thus, Bulk API 2.0 is the correct tool for both insertion and extraction at this scale, while simplifying operations and improving reliability.

Both Platform Events and Outbound Message offer declarative means for asynchronous near-real time needs. They aren't best suited for realtime integrations.

Number of concurrent subscribers to Platform Events is capped at 2,000. An Outbound Message configuration can pass only 100 notifications in a single messages to a SOAP end point.

Both Platform Events and Outbound Message are highly scalable. However, unlike Outbound Message, only Platform Events have Event Delivery and Event Publishing limits to be considered.

Explanation:

When comparing Platform Events and Outbound Messaging, it’s important to evaluate scale, reliability, and delivery characteristics. Both are asynchronous and near-real-time mechanisms and can be triggered declaratively (Apex, Workflow, or Process Builder).

Platform Events (PE) support multiple subscribers (up to 2,000), while Outbound Messages (OM) only target a single endpoint per configuration and support up to 100 messages per call (D). PE is more flexible for event-driven, publish-subscribe patterns across many consumers.

However, PE has strict event publishing and delivery limits (E), which can throttle high-throughput use cases. Outbound Messaging doesn't have such publish limits but lacks the scalability and retry customization offered by PE.

Option B is false — PE doesn’t guarantee message order or uniqueness, and messages may be delivered more than once. Option C is also incorrect — message sequencing is not guaranteed in OM and reliability varies.