Three times a year, Salesforce updates every org on the planet. Most of the changes are invisible. Some are not. The ones that are not tend to surface in the worst possible way: a sales rep cannot save a quote, a service case stops routing, a validation rule that worked yesterday throws an error today.
This playbook gives leaders a lightweight process that reduces that risk without turning every release into a two-week internal project. The goal is a repeatable routine that your team can run in a few focused hours per cycle.
What leaders should demand each release
Most Salesforce release problems are not caused by the platform update itself. They are caused by nobody reviewing what the update does before it reaches production.
Salesforce publishes release notes weeks before each production rollout. Sandboxes upgrade to the preview release before production does. That window exists specifically so teams can test. Most organisations do not use it, and then wonder why the release caused a problem.
The minimum standard a leader should hold the team to each release:
- Release notes reviewed someone with platform knowledge has read the notes and flagged updates relevant to your org’s configuration, active automations, and critical workflows.
- Enforced updates identified Release Updates that Salesforce is auto-enabling in this cycle are listed and tested in sandbox before the production date.
- Critical business processes tested the flows, approvals, and integrations that revenue depends on have been validated in the updated sandbox.
- Rollback plan exists if something breaks in production after the release, the team knows what to do and who to call.
That is not an extensive programme. It is four questions. If the answers exist and are documented before every production release, the org is in significantly better shape than most.
Release updates and the testing workflow
Release Updates are the subset of each Salesforce release that matters most for operational risk. These are platform changes that Salesforce will enforce, either optionally now or mandatorily in a future release. Skipping them does not make them go away. It means you find out what they break when Salesforce turns them on without your input.
The testing workflow for each release cycle follows the same sequence regardless of release size.
The sandbox preview window is the most valuable and most ignored step in this sequence. Sandboxes on preview instances upgrade before production. That gives teams a real-world environment with their own configuration to test against the new release. Using it is not optional for any organisation where Salesforce underpins revenue-critical processes.
For enforced updates specifically, the standard is to test them as early in the preview window as possible, not the week before production. An enforced update that breaks an automation needs time to fix. Testing it late removes that time.
Communication plan for users
Users who encounter unexpected changes in Salesforce without any warning lose trust in the system faster than any feature can rebuild it. A communication plan for each release does not need to be complex. It needs to exist and it needs to reach the right people before the change lands.
The communication model that works for most organisations has three components.
- Pre-release notice sent one week before production. Covers what is changing, which teams are affected, and where to get help if something looks wrong. Plain language, no technical jargon.
- Release day confirmation a short message confirming the release has gone live and whether everything is working as expected. If there are known issues, state them and give a resolution timeline.
- Post-release summary sent within a week. Highlights any new features that users can take advantage of, and closes the loop on any issues that were reported.
The teams that most frequently need advance notice are sales, service, and anyone using Salesforce daily for revenue-generating work. IT-only communication is not enough. If a change affects how a sales rep closes a deal or how a service agent resolves a case, those people need to know before it happens, not after.
For security updates, the communication should also include a brief explanation of why the change is happening. Users who understand the reason for a change adopt it more readily than users who experience it without context.
Change management for security updates
Security updates in Salesforce releases deserve specific attention because they carry compliance implications and because the consequences of ignoring them accumulate. An update that Salesforce marks as auto-enforced in a future release will be enforced whether or not the org is ready. The only choice is whether to be ready on your timeline or Salesforce’s.
Recent releases have included mandatory enforcement of OmniStudio security flags, changes to session handling in outbound messages, the deprecation of Connected Apps in favour of External Client Apps, and certificate lifespan changes that will eventually reduce rotation windows from 398 days to 47 days. Each of these required an action from technical teams. None of them were optional in the long run.
The change management approach for security updates follows this pattern:
- Identify the enforcement date not the release date. The enforcement date is when the behaviour changes in production regardless of org settings.
- Assess the impact which integrations, components, or user flows are affected. This requires someone with platform knowledge to test in sandbox before the enforcement date.
- Assign an owner security updates should have a named person responsible for testing and remediating, not just a team or a backlog item.
- Communicate to affected system owners integration owners and third-party vendors may need to make changes on their side. They need to know before the enforcement date, not after.
- Document the change what changed, what was tested, what the outcome was. This matters for audit trails and for explaining the change to regulators or internal compliance teams if asked.
Create an owner per release stream
Release readiness fails most reliably when nobody owns it. When the admin is responsible for their regular workload and release readiness at the same time, without protected time or a clear process, release readiness is always the thing that gets deprioritised. Until something breaks.
The model that works is a named release owner for each cycle, with defined responsibilities and protected time in the weeks before the production release. In larger organisations where multiple clouds are in use, a release owner per stream, Sales Cloud, Service Cloud, Data Cloud, and so on, distributes the work and ensures depth of coverage.
The release owner role does not require a senior technical architect. It requires someone with enough platform knowledge to read the release notes, identify relevant changes, coordinate testing, and escalate issues that need developer involvement. In many organisations that is a senior admin.
Rotation of the release owner role across team members builds institutional knowledge and prevents the situation where one person holds all the release context and the process collapses when they leave.
Metrics for release success
Measuring release readiness performance makes it easier to justify the investment and to identify where the process is breaking down. The metrics do not need to be complex. They need to be tracked consistently.
Production incidents within 72 hours of a release are the most useful single indicator of release readiness quality. An org that consistently has zero post-release incidents for two consecutive cycles has a process that is working. An org that has three incidents per release has a testing gap somewhere in the workflow.
Tracking deferred release updates is equally important for leaders because it reveals compounding risk. An update that was skipped in Spring and deferred to Summer, then deferred again to Winter, is an update that will eventually be enforced with far less preparation time than if it had been addressed in the original cycle.
Track incidents and regression causes
Every production incident that follows a Salesforce release should be logged with a brief root cause note. Not an extensive post-mortem, but enough to answer: what broke, why did it break, and why did testing not catch it.
Over two or three release cycles, that log reveals patterns. If incidents are consistently caused by integrations that were not included in the test plan, the test plan needs to be expanded. If incidents are consistently caused by enforced updates that were identified but not addressed in time, the timeline for the testing workflow needs to be compressed. If incidents are caused by user behaviour that changed because of a UI update nobody communicated, the communication plan needs to reach more people.
The log does not need to live in a sophisticated tool. A shared document with five fields per entry, date, release, what broke, root cause, and what changes to prevent recurrence, is sufficient. The value is in reviewing it before each new release cycle, not in the sophistication of the tracking system.
Releases become boring when readiness becomes routine. The organisations that have the fewest production incidents are not the ones with the most complex testing frameworks. They are the ones that run the same simple process every cycle without skipping steps.
TrueSolv can run release readiness on your behalf and manage the rollout across each Salesforce release cycle. Follow us on LinkedIn, YouTube or contact us directly to discuss how we can support your team.
