Salesforce Integration Testing Checklist: What to Test Before Go-Live

Salesforce integration testing often gets skipped because the demo went well. Picture a finance system pushing 200 invoice updates into Salesforce. Every record lands, everyone nods, and the project gets signed off. Two weeks later, sales spots dozens of accounts that exist twice. A batch of records never showed up at all, and nobody can explain why, because no one was watching the error log.

That story is made up, but anyone who has launched an integration will recognize it. A clean run under ideal conditions tells you very little about production. Live traffic means repeated messages, expired credentials, odd values, API ceilings and two people editing the same record in two different systems.

Testing is how you catch those problems while they’re still cheap to fix. Below, you’ll find what to test, how to test it and what a passing result looks like, so your go-live decision rests on evidence instead of a good demo.

What Is Salesforce Integration Testing?

Salesforce integration testing means checking that Salesforce and a connected system pass data back and forth correctly, cope with failures and hold up under realistic conditions. A live connection isn’t the finish line. You want to know the right data lands in the right fields, that errors get noticed, and that the integration picks itself back up after a problem.

Most teams end up combining a few kinds of testing:

• Functional integration testing checks that each data flow does what it was designed to do.
• Data validation testing makes sure values, formats and relationships survive the trip.
• Error-handling testing breaks things on purpose to see how the integration responds.
• End-to-end testing follows one business process through every connected system, from the first action to the final report.
• Performance and volume testing looks at how the integration copes with realistic record counts and bulk jobs.

Why Salesforce Integration Testing Matters Before Go-Live

Skipped testing rarely causes a dramatic outage. More often it causes slow, hard-to-trace data problems that people notice weeks later:

• Incomplete or wrong CRM records that reps act on
• Duplicate contacts, accounts or leads
• Failed or delayed transactions that nobody is told about
• API limit problems that knock over other integrations
• Permission failures that skip records without a sound
• Reports and downstream processes built on bad data
• Little visibility into what’s failing in production

All of these are cheaper to fix in a test environment than after customer data has been touched. Duplicates are the worst example. Once they’ve spread into reports and owner assignments, cleaning them up becomes a project of its own.

Salesforce Integration Testing Checklist: 10 Critical Areas to Test

Run these in a sandbox or another controlled test environment with representative data, not against live production records. How each area behaves depends on your integration’s design, configuration and business rules, so treat the pass criteria below as a starting point.

1. Field Mapping and Data Transformation

Mapping mistakes are among the most common causes of bad data, and they tend to fail quietly. A date nudged by a time zone, or a picklist value that exists on only one side, can corrupt a record without throwing a single error.

Try this: Send records built to be awkward: a blank optional field, a very long text value, a date just before midnight, a picklist value Salesforce doesn’t know and a name with a special character. Check data types, required fields and any transformation rules along the way.

A pass looks like: Values land in the right fields in the right format. Anything invalid is rejected or handled by a defined rule, not quietly altered.

2. Duplicate Record Prevention

Duplicates are easy to create and slow to remove. When reports, automations and owners are tied to the wrong record, merging stops being a quick fix.

Try this: Send the same contact twice. Then send the same person under a different email address. Repeat for accounts, leads or whatever else you sync, and search Salesforce for duplicates afterward. This test covers matching rules, unique identifiers and upsert behavior.

You want to see: Repeated payloads update the existing record. Anything the integration can’t match is flagged for review rather than created silently.

If HubSpot is part of your setup, our guide to preventing duplicate data between Salesforce and HubSpot goes deeper on matching behavior.

3. Failed Transactions and Error Handling

Every integration fails sometimes. What matters is whether anyone finds out, and whether the error carries enough detail to act on.

Try this: Send a payload that’s missing a required field. Send another that breaks a validation rule. Then take the connected endpoint offline for a short while and push a batch through.

A pass looks like: Each failure is logged with a clear reason, goes to a named owner and can be traced back to the source record. Good records in the same batch aren’t held up by bad ones, unless that’s how you designed it.

4. Salesforce API Limits and Usage

This one catches people out. According to Salesforce’s API request limits documentation, daily limits are enforced against the aggregate of all API calls made to the org over 24 hours. The limit isn’t per integration, so a new connection can eat into what every other system needs. The total depends on your edition and licenses, so look up your own org’s figures instead of assuming.

Try this: Estimate daily call volume from realistic record counts, then run a representative load. You can watch usage in Setup (the API Usage section and System Overview), in the Sforce-Limit-Info response header, or through the /limits REST resource. It’s also worth setting up API usage notifications so the right person gets an email before the ceiling is reached.

Salesforce limits long-running concurrent requests too. Exceeding that limit returns a REQUEST_LIMIT_EXCEEDED error, so include slow endpoints and heavy bulk jobs in this test. For more on how these ceilings shape design decisions, see our post on Salesforce API limits.

Success here means: Projected usage fits inside your allocation with room to spare. If a limit is hit, the failure is visible and the integration recovers instead of dropping data.

5. Retry Logic and Recovery

Retrying fixes temporary problems and makes permanent ones worse. A record that will always fail validation shouldn’t be resubmitted forever. A record that failed because an endpoint was briefly down should simply go through next time.

Try this: Cut the connection halfway through a batch, restore it and watch what happens. Then send a record that fails for good and make sure it isn’t retried endlessly.

A pass looks like: Temporary failures recover without manual work. Permanent ones stop retrying and land in a queue or log for review. Retries should also be idempotent, meaning a retried message leaves the same end state as one delivered once, so recovery never creates duplicates.

6. Authentication, Permissions and Access Control

Per Salesforce’s data access documentation, API calls respect the logged-in user’s object and field permissions, and fields hidden from that user aren’t returned. So an integration user who’s missing one field permission can behave strangely with no obvious error. At the other extreme, broad permissions such as View All Data or Modify All Data are a security risk.

Try this: Remove access to a single field and confirm the failure shows up somewhere. Let a test token expire, or rotate a test credential, and see how the integration reconnects. Check the integration user’s object permissions, field-level security and sharing access while you’re there.

A pass looks like: The integration user has the access it needs and nothing more. Permission and authentication failures are reported clearly, and credential changes don’t cause silent outages.

7. Data Reconciliation and Completeness

Matching record counts feel reassuring, but they don’t prove the data is right. Two systems can both hold 10,000 contacts while a few hundred have the wrong owner, status or amount.

Try this: Pull a sample of records and compare field values side by side. Compare totals for any amounts or counts that feed reports. List every rejected record and make sure each one has an explanation.

You want to see: The only differences are ones you expected, such as an intentional transformation. Every unexplained gap has been investigated and resolved.

8. Real-Time and Scheduled Synchronization

Two-way sync only works if the system knows which side owns each field. Without that, one edit overwrites another and nobody sees it happen.

Try this: Edit the same field in both systems within a short window. Then update a record and time how long the change takes to appear on the other side, whether your sync is real-time, scheduled or a mix of both.

A pass looks like: Delays stay within what was agreed. Conflicts resolve according to documented field ownership rules, and the winning value is predictable.

9. Performance and High-Volume Scenarios

An integration that handles ten records in a demo can act very differently with ten thousand, particularly when the load sits close to your API limits or arrives in bursts.

Try this: Run the volume you’d expect on a normal day. Then run a peak scenario, like a big import, a month-end close or a marketing campaign. Watch for timeouts, processing delays and throughput.

Success here means: The integration meets acceptance criteria agreed with the business. No single performance threshold suits every integration, so define the criteria before you test, not after you see the results.

10. Monitoring, Logs and Alerts

Testing tells you how the integration behaves today. Monitoring tells you how it behaves six months from now, after someone renames a field or a credential changes.

Try this: Cause a failure on purpose. Time how long it takes for the right person to find out, and check whether the log has enough detail to fix the problem.

A pass looks like: Failures trigger an alert that reaches a named owner. Logs show the record, the error and the time, and unresolved issues stay tracked until they’re closed.

Practical Salesforce Integration Test Cases

Use this table as the starting point for your own test plan, and add rows for the processes that matter to you. Expected results depend on the integration design, configuration and business rules.

Test scenario	What to verify	Expected result
New record creation	Required fields and field mapping	Correct record is created
Existing record update	Matching and update rules	Intended record is updated
Duplicate payload	Duplicate prevention or idempotency	No unintended duplicate is created
Invalid required field	Validation and error handling	Failure is recorded and visible
Temporary endpoint failure	Retry and recovery behavior	Transaction recovers according to the configured policy
API limit reached	Limit handling and recovery	Failure or delay is surfaced and handled appropriately
Permission restriction	Access and field-level security	Unauthorized operations are rejected safely
High-volume transaction	Throughput and processing behavior	Agreed acceptance criteria are met
Data reconciliation	Source versus destination values	Differences are identified and resolved

A Step-by-Step Salesforce Integration Testing Process

The tests above work best in a sensible order. This is the sequence we’d suggest.

1. Agree on requirements and success criteria first, so “working” means the same thing to everyone.
2. Map the systems, objects, fields and data ownership. You need to know which system is the source of truth for each important field. Salesforce’s Integration Patterns and Practices guide can help you choose a pattern that fits.
3. Prepare representative test data, including normal records, edge cases and a few deliberately bad ones.
4. Run positive and negative scenarios. Test what should work and what should fail.
5. Interrupt the connection and resend messages to check failure recovery and duplicate handling.
6. Reconcile source and destination values to validate completeness and accuracy.
7. Test realistic volumes, and confirm the integration user has the right permissions.
8. Review logs, monitoring and open defects, and check that alerts reach the right people.
9. Get business and technical sign-off. Both sides should look at the results.
10. Finish with a go-live readiness review using the checklist below.

If you’re reviewing an existing setup rather than a new build, a Salesforce health check shows where integrations sit within the wider org.

Common Salesforce Integration Testing Mistakes to Avoid

Most of these come down to testing only the happy path.

• Only testing success. For every scenario that should work, add one that should fail.
• Sending a message once and calling it done. Send the same one twice on purpose and see what happens.
• Using thin or unrealistic data. Test sets should reflect the shapes and volumes you actually see.
• Testing as an administrator. The real integration user is the one that matters, since that’s how permission gaps and expired credentials show up in testing rather than production.
• Trusting retry logic without proof. Check that it works, including the point where retries should stop.
• Treating record counts as evidence. Counts can match while values are wrong, so compare the values themselves.
• Forgetting who owns it after launch. Someone needs to watch the logs once the project team moves on.
• Launching with open critical defects. Decide upfront which defects block go-live.

Final Salesforce Integration Go-Live Checklist

• Field mapping verified
• Required fields and transformations validated
• Duplicate handling tested
• Failed transactions and recovery tested
• API usage reviewed
• Permissions and authentication verified
• Data reconciliation completed
• Performance tested against agreed criteria
• Logs, alerts and monitoring confirmed
• Critical defects resolved
• Rollback or recovery plan documented
• Business and technical sign-off completed

A ticked list isn’t a guarantee. Whether you’re ready depends on your integration, the systems it touches and what’s at stake if the data goes wrong, so change the list to suit your setup.

Conclusion: Make Integration Reliability Part of Go-Live Readiness

Testing a Salesforce integration shouldn’t end at “can these systems talk to each other?” What you really want to know is whether data arrives accurately, errors get caught, permissions are sensible, volume doesn’t break anything, failures recover and someone’s watching once the project team has moved on.

A good integration depends on the testing behind it. If you’re heading toward a launch or looking at a connection that’s already live, Amroar’s team can help. Read about our Salesforce integration services, or see how integrations sit within your wider Salesforce architecture.

Want a second opinion before go-live? Book a consultation to discuss your integration requirements or request an assessment.