Salesforce Release Readiness Playbook
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
