Publishing Cycle
A Publishing Cycle is the recurring schedule on which Salesforce produces, validates, and ships a major platform release to every customer org.
Definition
A Publishing Cycle is the recurring schedule on which Salesforce produces, validates, and ships a major platform release to every customer org. Salesforce runs three Publishing Cycles per year (Spring, Summer, Winter) on a fixed cadence, with sandbox previews available roughly four to five weeks before each cycle's general-availability date in production.
The term also appears in narrower contexts. Salesforce Knowledge has a publishing cycle for an article (draft, in review, published, archived). Experience Cloud sites have a publishing cycle for site changes (work in progress, preview, publish to live). In every variant, the cycle is the structured sequence of states a piece of content (the platform itself, an article, a site) moves through between authoring and being visible to its audience.
How the Salesforce Publishing Cycle anchors every customer release calendar
Three releases a year, fixed cadence
Salesforce ships Spring, Summer, and Winter releases each year. The pattern is roughly: Spring goes live in February, Summer in June, Winter in October. The exact production cutover dates differ by instance, so two orgs on different pods see the same release land on different weekends. Salesforce publishes the exact instance cutover calendar months ahead at status.salesforce.com, and customers plan their internal go-live windows around it.
Sandbox preview window
Roughly four to five weeks before each release goes live in production, Salesforce upgrades the Sandbox Preview pod (CS-numbered instances) to the new version. Customers can refresh a sandbox onto the preview pod to test their org against the release before it lands in production. The window is short and busy: change management teams compress regression testing, integration partners validate API behavior, and any release-blocking issue must be flagged to Salesforce Support during this window for the customer to get a meaningful response before production cutover.
Release notes and what they cover
Each cycle produces a release notes PDF roughly 600 pages long. The notes are organized by cloud (Sales, Service, Marketing, Platform, Industries) and feature area, with sections marked Generally Available, Beta, Pilot, and Retiring. Admins read the notes for their feature areas; developers read the API, Apex, and SOQL sections; security teams read the auth and SSO sections. Salesforce also publishes a Release in a Box site with videos, demo orgs, and webinars to help customers plan adoption.
Retirements and deprecations
Every cycle retires a small number of features and deprecates a slightly larger number. A retirement removes the feature from the platform on the release date; a deprecation announces a future removal date so customers can plan migration. The release notes have a clearly labeled Retiring section, and Salesforce sends pre-release email to every admin whose org uses an affected feature. The 18-month deprecation runway is the de-facto standard, but some retirements come faster when security or regulatory pressure forces them.
Knowledge article publishing cycle
Inside a Knowledge implementation, an article moves through four states. Draft is the authoring state, fully editable by knowledge workers. In Review (when an article approval process is enabled) freezes the content for moderation. Published makes the article visible on the chosen channels (internal, partner, customer, public). Archived removes the article from active channels while preserving it for audit and possible republish. The four-state cycle drives every Knowledge metric (cycle time, freshness, reuse) and shapes the editorial calendar for the documentation team.
Experience Cloud site publishing cycle
Experience Builder sites operate on a Publish workflow. Designers edit page layouts and themes in the Builder, which lives in a work-in-progress state. Preview lets administrators view the site as a logged-in or guest user without exposing the changes to the world. Publish promotes the work-in-progress version to the live site for all visitors. The cycle supports rollback to a previous published version if a deploy breaks something, and tracks each publish event with author and timestamp for audit.
Aligning customer change windows to the platform cycle
Most mature Salesforce customers align their internal release train to the platform cycle. The pattern is to freeze production changes the week of each Salesforce release cutover, run the pre-release sandbox validation, then resume customer-driven changes the following week. Customers who skip this alignment routinely discover their integrations break the Monday after a Salesforce release because a deprecated API behavior they relied on disappeared, and their on-call developer is debugging at the same moment the customer's own change train is trying to ship.
Plan and execute a Salesforce release window
Use the published Salesforce Publishing Cycle to plan sandbox validation, internal regression, and production cutover so your org lands on the new release without incident.
- Pull the release calendar
Visit status.salesforce.com and look up your instance maintenance window. Note the production cutover date and the preview pod upgrade date.
- Refresh a sandbox onto the preview pod
Identify your full-copy sandbox. Two days after the preview pod upgrades, refresh the sandbox so it lands on the new release. The refresh wipes any in-flight work; coordinate with developers first.
- Run automated regression
Trigger your Apex unit tests, integration sanity scripts, and any UI smoke suite against the refreshed sandbox. Capture failures with stack traces. Differentiate platform-caused failures from in-flight feature breakage.
- Read the release notes for your features
Open the release notes PDF. Skim the index. Read the Sales Cloud, Service Cloud, Platform Apex, and any industry-cloud sections relevant to your org. Flag any deprecations that hit your code.
- File support cases for blockers
For any regression issue you cannot explain, open a case with the case template Release Issue. Reference the release name and the specific sandbox instance. Cases filed during the preview window get priority routing.
- Freeze and validate on cutover weekend
The week of the production cutover, freeze your internal change set deploys. The Monday after, run a single smoke pass against production. Resume normal change management once verified.
CS-numbered sandbox pod that receives the new release four to five weeks early. Refresh a sandbox onto it to test.
Salesforce-hosted site with demos, videos, and a slide deck for each release. Built for admins to socialize the release internally.
Specific platform changes flagged for activation. Some are auto-activated on the release; others give admins a window to opt in.
The roughly 600-page document that lists every change in the cycle. Indexed by cloud and feature area.
- Salesforce will not let you skip a release. Every org is on the latest version after the cycle cutover. There is no opt-out or version pinning.
- The preview pod is shared. Refreshing a sandbox there during the busiest week of preview testing can take several hours because the pod is at refresh capacity.
- Deprecation runways close. A feature deprecated 18 months ago will be retired this cycle. Read the Retiring section in detail, not just the new feature highlights.
- Knowledge and Experience Cloud publishing cycles are separate from the platform cycle. A platform release does not auto-publish your draft articles or site changes; those still need their own publish actions.
Trust & references
Cross-checked against the following references.
- Salesforce Release Cycle OverviewSalesforce Help
- Salesforce Maintenance ScheduleSalesforce Trust
- Release Readiness BlogSalesforce
Straight from the source - Salesforce's reference material on Publishing Cycle.
- Release Cycle OverviewSalesforce Help
- Knowledge Article PublishingSalesforce Help
- Publish an Experience Cloud SiteSalesforce Help
Hands-on resources to go deeper on Publishing Cycle.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What is the Publishing Cycle?
Q2. What automates the cycle?
Q3. Why invest in publishing cycle design?
Discussion
Loading discussion…