Salesforce Integration Testing Before Go-Live: APIs, Flows, and Downstream Systems

Salesforce integrations rarely fail because nobody checked whether an endpoint could connect. They fail because an opportunity reaches ERP without a required product value, a lead arrives twice from marketing, a platform event is processed out of sequence, a scheduled sync misses its window, or a rejected payload sits unnoticed while customer records diverge.

A useful Salesforce integration test starts with the business outcome, not the interface name. A lead, quote, order, case, consent update, or account change should be traceable from the initiating event through every system and team that depends on the result.

Build an integration inventory around business outcomes

List every inbound, outbound, scheduled, event-driven, API, file-based, and middleware integration in scope. Then record the business event it supports, the source and target owners, timing, data moved, success confirmation, dependencies, and what must happen when it fails.

• —Customer and revenue operations: lead capture, marketing automation, account enrichment, CPQ, contract lifecycle management, orders, ERP, invoicing, and payments.
• —Service and customer experience: telephony, customer portals, chat, field service, entitlement systems, knowledge platforms, surveys, and escalation tools.
• —Identity and access: identity providers, single sign-on, provisioning, deprovisioning, integration users, certificates, connected apps, and service accounts.
• —Data and analytics: ETL or data sync jobs, data warehouses, master data, business intelligence, regulatory extracts, and operational reporting feeds.
• —Integration mechanisms: REST and SOAP APIs, MuleSoft or other middleware, outbound and inbound Flows, platform events, Apex callouts, Bulk API jobs, and scheduled processes.

Test payloads beyond the happy path

A tidy test record proves very little about whether an interface can support production conditions. Integration UAT should test the imperfect payloads, conflicting updates, limits, and partial outcomes that operations will need to recognise and recover.

• —Valid records across all in-scope record types, currencies, products, territories, consent states, and reference-data combinations.
• —Malformed dates, invalid picklist or reference values, missing mandatory fields, unexpected nulls, and data that should be rejected safely.
• —Duplicate records, repeated messages, and retried requests, with proof that idempotency controls prevent duplicate leads, orders, cases, or financial outcomes.
• —Mixed batches where some records succeed and some fail, with a usable route to isolate, correct, and rerun only the failed records.
• —Governor limits, API limits, Bulk API batching, timeouts, response-size constraints, and realistic data volumes rather than a single-record demonstration.

Run end-to-end sequences with realistic timing

An interface can be correct in isolation and still break the broader journey. A quote may be approved after the ERP batch cutoff, a campaign response may sync after routing rules have changed, or a scheduled Flow may run before an upstream job completes. Test the sequence and timing that production will impose.

• —Create the source event in Salesforce using the representative user, record type, approval state, and data condition.
• —Verify that the Flow, API call, platform event, middleware route, or scheduled job triggers at the intended point.
• —Check that the target system receives the correct identifiers, values, status, dates, ownership, and related records.
• —Confirm acknowledgements, error queues, dashboards, and reconciliation reports are visible to people who need to act.
• —Test boundary conditions such as batch windows, scheduled Flow runs, near-real-time sync, month-end close, peak volumes, and the cutover window.

Prove failure, alerting, retry, and recovery

A go-live-ready integration has a safe failure mode. The operating team should be able to see what failed, understand the business impact, prevent duplicate processing, correct the root cause, rerun the affected work, and prove that Salesforce and the target system have returned to a complete and accurate state.

• —Simulate an unavailable endpoint, expired credential, invalid token, malformed payload, missing required value, and target-system rejection.
• —Confirm alerts reach the accountable business and technical teams with enough context to investigate and prioritise the incident.
• —Check retry rules, timeouts, dead-letter or error queues, duplicate protection, and the point at which a human must intervene.
• —Run the documented recovery process and reconcile record counts, identifiers, statuses, and financial or customer outcomes across systems.
• —Capture named ownership for each integration during cutover, first-day operations, and ongoing support.

Include integrations in the cutover rehearsal

The final proof is a timed rehearsal of the real switch-over: final data loads, connected-app and credential activation, middleware deployment, Flow and schedule enablement, first batch and near-real-time runs, exception monitoring, and the first material business events. This is where dependency order, access, timing, and support gaps become visible while the team can still fix them.

“The test is not complete when Salesforce sends or receives a payload. It is complete when the business event is accurate, visible, recoverable, and reconciled everywhere it needs to be.”