Salesforce Regression Testing Before Go-Live: What to Recheck After Change

A Salesforce change can look contained in a release note and still have a wide business impact. A revised Flow, validation rule, permission set, object field, Apex trigger, or record type can alter what a user can create, which approval starts, what automation runs, what data leaves the organisation, and what leaders see in their reports.

That is why Salesforce regression testing is not a generic rerun of yesterday's scripts. It needs to prove that the journeys affected by change still work for the people, data states, sharing rules, timing, and exceptions that will exist in production.

Start with change impact, not a list of test cases

Before selecting tests, trace the change through the operating model. Ask which user or system starts the event, which objects and fields it reads or updates, which Flows, approvals, integrations, and reports depend on it, and which roles could lose access or receive the wrong outcome.

• —A Flow change can alter field updates, approval entry criteria, notifications, task creation, outbound messages, and related-object automation in the same transaction.
• —A permission-set or profile change can prevent a seller from progressing an opportunity, expose sensitive fields, or leave an approver unable to act on a record.
• —An object, field, or record-type change can affect validation, page layouts, formulas, reports, API mappings, and historical data without producing an obvious deployment error.
• —A sharing-rule change can make a record invisible to the team that must service it, or visible to a population that should not have access.
• —An Apex or integration update can pass a single-record check but fail when bulk updates, scheduled jobs, retries, or production data volumes apply.

Recheck the customer and worker journeys that cannot fail

Every Salesforce organisation has a small number of journeys where a defect immediately affects revenue, customer experience, compliance, or operations. These are the non-negotiable core of a regression pack even when the release window is tight.

• —Lead-to-opportunity: lead capture, assignment, conversion, account and contact creation, opportunity access, stage progression, and sales hand-off.
• —Quote-to-cash: product and price selection, discount approvals, quote generation, contract or order creation, ERP hand-off, invoicing status, and revenue reporting.
• —Case management: case intake, routing, entitlement or priority logic, agent access, escalation, customer communications, closure, and knowledge or survey follow-up.
• —Approval processes: entry criteria, routing, delegated approvers, rejected and recalled requests, notifications, and the record updates that occur after a decision.
• —Account and contact maintenance: duplicate handling, consent or preference updates, ownership changes, related records, and marketing or service-system synchronisation.

Include security, reporting, and integration regression

A transaction can complete successfully for an administrator while still failing in production. The sales rep may not see the account, the service manager may receive an incomplete dashboard, or the ERP may receive a record with the wrong status. Regression testing must use the real access model and operating controls that go live.

• —Run key scenarios as the sales representative, sales manager, service agent, finance user, marketing user, system integration user, and delegated approver who will perform them.
• —Validate profiles, permission sets, permission-set groups, field-level security, role hierarchy, sharing rules, queues, and manual sharing after every access-related change.
• —Compare critical reports, dashboards, and exports to agreed record counts and values; do not accept a report merely because it loads.
• —Exercise integration success, rejection, retry, and recovery paths, including the alerts and ownership procedures needed when a sync or outbound message fails.
• —Confirm scheduled Flows, batch jobs, report refreshes, and effective-dated commercial processes behave correctly at the times the business relies on them.

Use production-like data and evidence

Regression results are credible only when test data represents the conditions that make a Salesforce organisation difficult to run: accounts with multiple contacts and opportunities, different record types, complex sharing, incomplete fields, duplicate candidates, approval thresholds, legacy records, and realistic downstream identifiers.

Record the scenario, user role, starting data state, expected result, actual result, evidence, defect reference, and owner for every material test. This makes the go-live decision traceable and turns a passing status into evidence that business owners can review.

Set clear regression exit criteria

A release is not ready because every planned script is green. It is ready when critical journeys are proven with representative users and data, security and report outcomes are checked, integration and recovery paths have named owners, and material defects are resolved or explicitly accepted by the people accountable for sales, service, finance, and operations.

“The purpose of Salesforce regression testing is not to repeat every historical test. It is to find the specific places where today's change can make tomorrow's customer or commercial process fail.”