Updated October 5, 2026.
A CRM update can leave every screen available while sending a lead to the wrong queue, skipping an approval or changing a report total. CRM regression testing checks whether existing business workflows still behave as agreed after a platform upgrade, configuration change, integration update or custom release.
Start with the change list and the journeys your sales, service and operations teams depend on. This guide gives you 15 practical checks to adapt to your product. They are recommended scenarios, not claims of defects found in a client project. For hands-on coverage of browser-based CRM products, explore our web application testing services.
Before testing: agree the change, roles and expected results
Record the release version, changed fields and rules, affected integrations, approved permissions and business owners. Use a representative test environment and synthetic or approved sanitized data. Prevent test emails, payments and automated messages from reaching real customers.
For Salesforce, consult the release updates applicable to your organization and test in its preview environment. Salesforce describes three seasonal releases and a sandbox-preview window before production upgrades in its release schedule guidance. Check your actual upgrade date; this checklist does not assume every organization receives the same change at the same time. For Dynamics or a custom CRM, use that product’s release notes and configured business rules.
15 CRM workflows to recheck after an update
1. Lead capture and required fields
Run: Submit a lead through the CRM and a connected test form using valid, missing and boundary-value inputs. Expect: Approved validation rules apply, accepted data is saved correctly and rejected submissions explain what to correct. Keep the form payload and resulting record ID as evidence.
2. Assignment and reassignment
Run: Create records that match different routing conditions, including a condition with no matching owner. Reassign an existing record. Expect: Ownership, queue membership, visibility and notifications follow the approved rules. Check both the previous and new owner’s views.
3. Duplicate detection and merging
Run: Create similar records through the UI and an integration, then exercise the supported merge process. Expect: The configured duplicate policy is applied; related activities and references remain attached correctly. Do not assume every repeated email must be rejected—confirm the business rule.
4. Qualification and conversion
Run: Move a lead through qualification into the supported account, contact and opportunity workflow. Expect: Field mappings, ownership and relationships survive conversion, including paths using an existing account. Record the source and destination IDs.
5. Record and field permissions
Run: Use separate accounts for each approved role to view, create, edit, delete and export records. Include direct URLs and authorized API checks where in scope. Expect: Both allowed and denied actions match the permission specification; hiding a UI control alone is not sufficient evidence.
6. Role changes and active sessions
Run: Change a test user’s team or permissions while an existing session is open, then repeat access checks after refresh and sign-in. Expect: Access changes take effect according to documented session rules, without retaining unauthorized visibility.
7. Approval workflows
Run: Submit, approve, reject and resubmit a record, including an unavailable approver where supported. Expect: The correct person can act, status transitions are valid and actions are not duplicated. Capture the approval history rather than relying only on a success banner.
8. Tasks, notifications and field updates
Run: Trigger an automation through each supported entry route, including an integration update. Repeat or retry the action. Expect: The intended task, message and field change occur once or according to the specified repeat policy, for the right recipient.
9. Timers and escalation rules
Run: Test just before and after timer boundaries, with relevant time zones, business hours and completed or cancelled records. Expect: Escalations occur only when eligible and stop when the qualifying condition no longer applies. Preserve timestamps and job evidence.
10. Two-way integration synchronization
Run: Create and update a synthetic record from the CRM and from a connected system. Include conflicting edits. Expect: Mappings, source-of-truth rules and permitted propagation match the specification. Compare IDs and field values on both sides, not just an API success response.
11. Integration failures and retries
Run: Simulate an expired test credential, timeout, rejected payload, rate limit and duplicate delivery in an approved environment. Expect: Failed work is observable, retry behavior is bounded and recovery does not create duplicate business actions. Confirm webhook signatures and authentication checks where applicable and in scope.
12. Imports and bulk updates
Run: Import valid and invalid rows together, then retry the rejected subset. Include dates, empty values and field transformations. Expect: Accepted, rejected and skipped totals reconcile; errors identify affected rows; existing relationships are preserved.
13. Reports and dashboards
Run: Build a small known dataset, change stages and owners, and compare report results under different roles. Expect: Filters, totals, currency rules and historical periods match the source data and access rules. Account for documented refresh delays before recording a mismatch.
14. Exports and audit history
Run: Export an agreed record set and review the history of edits, approvals and ownership changes. Expect: Exported fields respect permissions; records and values reconcile; audit entries identify the relevant actor, action and time according to the product’s requirements.
15. Cross-role, browser and mobile handoff
Run: Have one user create or update a record and another permitted user continue the workflow on a supported browser or mobile interface. Include refresh, interrupted connectivity and session expiry. Expect: Authorized users see the correct state without lost input or controls becoming inaccessible.
Discuss Your CRM Regression Scope
Build a role-by-workflow matrix, not a universal permission table
“Manager” does not automatically mean access to every customer record, and an administrator may still have restrictions. Fill the matrix from approved policies before testing. For each role and workflow, record the following:
- Record boundary: own records, team records or another explicitly permitted set.
- Allowed actions and restricted fields, including exports and API access.
- Expected automation context: the initiating user, service account or configured execution identity.
- Positive and negative tests, expected results and evidence.
Salesforce’s flow-access guidance identifies affected and unaffected flow types. Assess applicability rather than assuming every automation is affected. That reference describes Winter ’26 enforcement; it is not presented here as a new October 2026 announcement.
A lesson from our multi-role QA work
In previously documented, anonymized multi-role application work, our team checked whether actions and data in one user area appeared correctly in other permitted user areas across web, iOS and Android. A reported sign-in issue affected access to a key flow. This is why a regression plan should begin with access and continue through the cross-role handoff—not stop after checking each screen separately.
Client identifiers and proprietary module names are omitted. This example does not establish a Salesforce or Dynamics implementation, a confirmed root cause, a completed fix or a measured business outcome. Rechecking sign-in and the dependent role handoff is a recommended regression follow-up, not a claim that it was added and executed.
What to automate and what to review manually
Consider automation for stable, repeatable record creation, mapping assertions, permission checks and report reconciliation when controlled data and reliable cleanup are available. Human QA should review changed business rules, unexpected cross-role behavior, usability and ambiguous results. Neither approach removes the need to maintain expected outcomes after configuration changes.
Our automation testing services can support an explicitly agreed automation scope. For recurring release coverage, QA On-Demand provides a route to discuss ongoing testing capacity. For broader tenant and subscription concerns, see SaaS application testing.
Plan the testing window before the upgrade
Prioritize access failures, incorrect ownership, data exposure, blocked conversions and failed integrations according to business impact. Reserve time for fixes and a separately agreed retest window. A passed sample does not prove every combination works: report the exact roles, data, environments and workflows checked, plus blocked and untested areas.
Ask your QA provider to estimate the changed workflows, roles, integrations, browsers/devices, data setup, builds and execution cycles. Retesting and regression scope must be explicit in the proposal. Use our QA pricing and engagement guide for budgeting context instead of assuming every release has the same effort.
CRM regression testing questions
What should be tested after a CRM update?
Test changed functionality, its dependencies and critical existing journeys. Prioritize sign-in, permissions, lead conversion, ownership, automations, integrations and data/report reconciliation according to the release’s impact.
How do you test CRM workflows?
Define the starting state, user role, action and expected state at every handoff. Execute valid and invalid paths, then verify downstream records, tasks, notifications and audit evidence.
How do you test Salesforce permissions?
Use test users with the actual profiles, permission sets and sharing configuration in scope. Check permitted and prohibited actions against approved expectations, including record access, field access and applicable flow execution.
How do you test CRM integrations?
Validate mappings and state on both systems for successful and failed exchanges. Include retries, duplicate or delayed events, credential failures and reconciliation after recovery.
How do you validate CRM data after migration?
Reconcile source and destination counts, identifiers, relationships and transformed values. Check rejected rows, duplicates, access boundaries and representative reports. Counts alone cannot establish data accuracy.
Does every update require a full regression run?
Not necessarily. Select coverage based on the change and its dependencies, while retaining critical business journeys. Broaden testing when changes affect shared permissions, data models or integrations, or when the impact is uncertain.
Get a regression plan for your next CRM release
Share your CRM platform, upcoming changes, user roles, critical integrations and release date. We’ll recommend the regression coverage needed before release. Start with a sanitized scope summary; do not submit passwords or customer records through the inquiry form.
