SAML SSO and just-in-time provisioning

OpenId Connect Authentication Provider and just-in-time provisioning

Explanation:

To provide instant community access on first login, Salesforce must auto-provision users when they authenticate via SSO.

→ SAML SSO + JIT: You configure a SAML identity provider and enable Just-in-Time provisioning so that Salesforce consumes assertion attributes (e.g., Federation ID) to create the user, contact, and profile in one transaction.
→ OpenID Connect + JIT: You set up an OpenID Connect Authentication Provider in Setup and implement a Registration Handler class (Auth.RegistrationHandler) that Salesforce invokes on login, using the ID token claims to spin up the user record automatically.

Without JIT, you’d force users through a manual registration flow or pre-provisioning process, delaying access and complicating self-registration.

To subscribe to an event, the integration user in salesforce needs read access to
theevent entity.

To publish an event, the integration user in salesforce needs create permission on the event entity.

Error handling must be performed by the remote service because the event is effectively handed off to the remote system for further processing.

Explanation:

Platform Events are an asynchronous, event-driven communication mechanism that decouples publishers from subscribers. To subscribe to events, users or external systems must have read access, while publishing events requires create access. These permission checks ensure only authorized integrations participate in the messaging lifecycle.

Since the publisher "fires and forgets" the event, the system has no control over what happens once the message is delivered. This means error handling must be managed by the external system consuming the event. It must validate payloads, ensure message processing, and handle retries or failures independently. Platform Events are durable for 1–3 days (depending on edition), giving consumers a time window to retrieve missed events. But the responsibility for robust error management remains with the consumer system.

The endpoint domain has been added to Cross-Origin Resource Sharing.

Explanation:

When a Lightning Web Component (LWC) performs a callout to an external service, Cross-Origin Resource Sharing (CORS) is the first thing to check if the request is failing. CORS is a browser security mechanism that blocks cross-origin requests unless explicitly allowed by the server and registered in Salesforce’s CORS settings.

Salesforce requires the external domain to be added under CORS Whitelist Settings in Setup so that browser-based requests from the LWC are permitted. If the domain isn’t registered, the browser will block the request before it even reaches the server.

Other settings, like Remote Site Settings and Content Security Policies, are used for server-side callouts (Apex) and UI security respectively, but they do not apply to LWC client-side callouts.

Ensuring the endpoint is listed in CORS resolves many callout issues and is typically the first validation step when integrating LWCs with external APIs.

ERP, Inventory, Pricing Engine, Invoices system

Explanation:

To support quoting in Salesforce you need ERP integration for master pricing (ERP + Pricing Engine). To show current stock you integrate Inventory. To surface invoices you integrate the Invoices system. Although the BI tool and data warehouse consume Salesforce data, they typically read from those operational systems or Salesforce analytics directly; you don’t integrate them back into Salesforce. MDM (customer master) is usually synched upstream into Salesforce already. Data Warehouse (A/C/D) and BI Tool aren’t sources of transactional data needed for quoting and fulfillment in the Salesforce UI.

Remote Process Invocation-Fire and Forget

Explanation:

When the workshop registration system is expected to experience a surge of traffic (e.g., when the conference schedule goes live), synchronous integrations (like request-reply) can introduce bottlenecks and user-facing delays or failures.

The Fire and Forget pattern allows Salesforce to submit a registration request to the scheduling system without waiting for an immediate response. This is more scalable and helps absorb traffic spikes without slowing down the user experience. The scheduling system can then process registrations asynchronously and send confirmation later if needed.

This pattern is ideal for surge conditions, especially when the backend system might struggle with real-time concurrency but can handle queued processing.