Salesforce ships three major releases a year — Spring, Summer, and Winter. Each one brings hundreds of changes, some of which will affect your org in ways you didn't anticipate.
Most teams handle releases reactively: something breaks, they fix it, they move on. The teams that handle them well are the ones who do a structured pre-release audit and catch the problems in sandbox before they hit production.
Here's the audit checklist that actually prevents incidents.
1. Review Salesforce Release Notes for Your Feature Set
This sounds obvious, but most teams skim the release notes looking for new features and miss the deprecated features and changed behaviours buried further down.
Focus on:
- Retired features (are you using any of these?)
- Changed API behaviours (do your integrations hit any affected endpoints?)
- Automation changes (any updates to Flow execution, governor limits, or trigger order?)
- Security and permission changes (anything affecting your sharing model or field-level security?)
Allocate an hour to reading the sections relevant to your feature set, not just the headline announcements.
2. Audit Your Active Automations
Run a report of all active Flows, before they receive the release update in your sandbox. Check specifically:
- Any Flows that reference features being deprecated
- Flows with hard-coded API names or IDs (these break on object/field renames)
- Scheduled Flows that run during the release window (Salesforce releases typically deploy on weekends — verify your scheduled jobs aren't running then)
This is also a good time to deactivate Flows that are no longer needed. Fewer active automations = fewer things that can break.
3. Review Your API Integrations
For each external system integrated with Salesforce, identify:
- Which Salesforce API version is the integration using?
- Are any of the objects or fields it accesses being affected by the release?
- Is the integration using any deprecated API endpoints?
Salesforce retires old API versions on a rolling basis. If your integration is using API v30 or earlier, it's time to upgrade — not just before this release, but urgently.
4. Check Your Custom Code for Deprecated Methods
If your org has Apex classes or Visualforce pages, search your code for any methods or classes flagged in the release notes as deprecated.
A quick search in Developer Console or VS Code for the deprecated class/method names will surface the issues before they become compile errors post-release.
5. Audit Permission Set Assignments for New Features
Many Salesforce releases introduce new features that require explicit permission grants — they're not automatically available to existing users. Check the release notes for any new permissions relevant to your org and decide in advance which profiles or permission sets should receive them.
Also check: are any existing permissions being changed? Some releases tighten default access; verify nothing your team relies on is being silently restricted.
6. Refresh Your Sandbox and Test Pre-Release
Salesforce typically makes the upcoming release available in sandboxes 4–6 weeks before production deployment. Use this window to:
- Refresh your staging sandbox with a recent production copy
- Allow the pre-release update in sandbox settings
- Run your regression test scripts against the updated sandbox
Any issues found here can be fixed before the production release window.
7. Communicate the Release Window to Your Team
One of the most preventable incidents I've seen: a team runs a data migration or complex automation job during the Salesforce maintenance window for a major release, it fails mid-run, and the rollback takes days.
Share the release dates with your operations and development teams. Mark the maintenance windows as off-limits for deployments and major data jobs.
MeetTheMind Insight 💡
The orgs I've seen handle releases most smoothly treat the pre-release period like a mini-project: there's a dedicated slot on the sprint, someone owns the audit, and findings have a clear resolution path.
The orgs that struggle are the ones where "reviewing the release notes" is technically everyone's responsibility, which means it's effectively nobody's. Assign one person to own the pre-release audit for each major release. That single change eliminates most of the reactive fire-fighting.
Key Takeaways
- Read the deprecated features section of release notes, not just the new features
- Audit active Flows for references to deprecated methods or hard-coded IDs
- Check API version currency for all external integrations
- Test against the pre-release sandbox 4–6 weeks before production deployment
- Assign one person to own the pre-release audit — don't make it everyone's job
- Block the release maintenance window for deployments and data operations