Salesforce Integration QA: What to Test Before Client Launch

An integration can return a successful response and still put the wrong value on the wrong record. Before a client launch, test the business behavior end to end: record matching, field transformations, associations, permissions, retries, and what operators see when a request fails. The test plan should reflect the agreed scope and the connected systems in that project. It should not assume that every Salesforce org or connector behaves identically.

Establish the test boundary

Write down which systems, objects, fields, and events are in scope. Identify the direction of data flow and whether updates travel one way or both ways. Note which environment is being tested, what credentials and permissions are used, and what is deliberately excluded. If a workflow changes ownership or sends an external message, identify the safeguard that prevents accidental production activity during testing.

Define a stable test record or correlation value so a request can be followed across systems. Agree on who can create or edit test records and where logs may be reviewed. Avoid putting secrets or sensitive payloads into shared notes. If production data is needed to reproduce a case, use the client’s approved process and minimize the fields copied into the test artifact.

Turn each requirement into a pass/fail statement. “Sync should work” is not a test. “When an approved opportunity changes to the agreed stage, the destination record receives the mapped stage and the expected account association, without creating a second record on retry” is testable. Ask the client to approve the business meaning before measuring the implementation against it.

Check mapping and record matching

Test every field that affects routing, reporting, eligibility, or downstream actions. Verify data type, allowed values, blank handling, and transformation. Use test cases for ordinary values and edge cases such as a missing phone, an unexpected picklist value, a date near a timezone boundary, and a long text value. Confirm the destination behavior rather than only inspecting the outgoing request.

Test how records are matched. Use a new record, a known existing record, a record with a changed identifier, and a duplicate candidate. Confirm the integration updates the intended record and preserves associations. If it cannot confidently match a record, the safe outcome may be an exception for review, not an automatic create. Write down which fields form the key and how collisions are handled.

If data can move in both directions, test conflict behavior. What happens if both systems change the same property before synchronization? Which source wins, or is the conflict held for a person? A bidirectional connection without a stated conflict rule can overwrite a correct value with a stale one. Test the rule using controlled records and note the timestamps and expected result.

Exercise retries and failure paths

Test a transient failure and confirm the retry does not create a duplicate or repeat a consequential side effect. Test a permanent error such as invalid data and verify that it becomes visible rather than retrying forever. If the integration uses a queue or a connector-managed retry, document what the operator can inspect and whether a retry is automatic or manual. Do not claim delivery guarantees that the underlying product does not provide.

Check alerts and exception details. An actionable alert identifies the record or correlation key, the failed operation, the time, and the next owner. It should not expose a full sensitive payload to a broad channel. Ensure an operator knows whether the record is safe to retry, needs correction, or must wait for client approval. A generic “sync failed” message is not enough for recovery.

Test idempotency for actions that might be triggered more than once. Replaying an event should not send two customer messages, create two tasks, or add duplicate records unless that is the intended behavior. If the connector has no built-in idempotency control for the action, describe the limitation and propose a review or deduplication step within the agreed scope.

Verify permissions and operational ownership

Confirm the integration identity can perform required actions and cannot access unrelated data where roles allow that distinction. Test the minimum practical permission set, and confirm what happens when an account token expires or an administrator changes access. The client should know which account owns the connection and how to rotate its credentials through its normal security process. Avoid shared user accounts that obscure who made a change.

Identify who monitors the integration after launch, how often exceptions are reviewed, and who approves changes to field maps or workflow conditions. Document where logs are available and any retention limits that affect troubleshooting. If the consultancy provides ongoing support, define the response boundary and what requires a separate change request. The client still needs an internal owner for business decisions and account access.

For release, agree on a pause or rollback action. If a high-impact pattern appears, the operator should know how to stop new activity, preserve enough evidence to investigate, and communicate the issue. The exact recovery procedure depends on the integration and should be rehearsed for critical flows. Do not assume that disabling a connection reverses records or messages already processed.

Sign off with evidence

Keep a compact test matrix: requirement, input, expected behavior, actual behavior, result, and evidence location. Include normal, excluded, incomplete, duplicate, retry, permission, and exception scenarios where they apply. Record the software environment and test date, but do not make the report look more comprehensive than the cases actually run. Any skipped scenario should be visible with its reason and owner.

Before client acceptance, review open defects, limitations, dependencies, and the first monitoring date. Ask the client to confirm the business rules and demonstrate how to locate an exception. If a test fails, assign an owner and repeat that case after correction. If a requirement changes, update the specification and assess which other tests are affected.

The useful outcome is not a perfect-looking test sheet. It is a shared understanding of what the integration does, what it does not do, and how the client will notice and handle an unexpected result. See CRM and RevOps implementation support, a sample workflow, or request a scoped workflow demo to discuss a bounded example before production access is considered.