The 29-day sandbox and other deployment stories

Release engineering on Salesforce is hard because the platform was built for configuration, not for shipping it. Change sets move in one direction and can't be rolled back, several metadata types don't travel at all, configuration stored as data records leaks through the cracks, and a full sandbox refreshes only once every 29 days. Add three vendor releases a year and the process spends most of its energy compensating for the tools rather than using them.

Why can't a change set be rolled back?

A change set is a one-way promotion. You build an outbound set in one org, upload it, and deploy it inbound in another. There is no undo button. When a deployment breaks production you don't revert it — you hand-assemble a second change set that reverses the first, test it under pressure, and deploy forward again. The mechanism is point-and-click and genuinely easy to start with, which is exactly why teams are still leaning on it years into a build. Analyses of the approach, including Gearset's write-up on change sets, are blunt about the two structural limits: a deployed change set can't be deleted or reverted, and it carries only a subset of the platform's metadata types.

The types it won't carry are the ones that hurt. Anything a change set skips has to move another way — a manual step, a script, or a click-by-click rebuild in the target org — and every one of those is a place for two environments to quietly diverge. It is also why deployments tend to pile onto the same small group that already owns everything else fragile: the integration team everyone ends up waiting for.

What is the 29-day sandbox wall?

A full sandbox is the only environment that copies production data and configuration faithfully, and Salesforce documents its refresh interval as once every 29 days (as of June 2026). Developer and partial-copy sandboxes refresh far faster but carry less of production with them, so the one environment you actually trust for final regression can be rebuilt at most once a month. That single number shapes an entire release calendar. If two projects share the full sandbox, a refresh wipes one team's in-flight work to serve the other's; refresh mid-project and you lose seeded test data and re-established integrations along with it.

The predictable outcome is that teams stop refreshing. A long-lived full sandbox drifts away from production over weeks — accumulating half-finished features, stale records and manual fixes that were never captured anywhere — until the environment you built to catch drift has quietly become a source of it. Your final regression pass then runs against a target that no longer matches the org you are deploying into.

Why do configuration records refuse to deploy?

Not everything that configures the system is metadata. A large amount of behaviour lives in records: custom settings rows, custom metadata type records used as configuration, and reference data that automations read at runtime. Change sets and the Metadata API move metadata, not arbitrary data, so this layer doesn't ride along with the rest of a release. The boundary is confusing precisely because the same feature can sit on either side of it — a custom metadata type definition is metadata, but the specific rows a flow depends on at runtime may not travel with it.

Practitioners document the usual escape hatches — exporting and re-importing rows, data-loader scripts, or third-party utilities such as those from Xappex — and an entire cottage industry exists to fill that gap. Each workaround becomes another undocumented step in a runbook that only one person remembers, executed by hand at the least forgiving moment of the release.

Here is where a typical release leaks, and what teams end up doing instead:

The problem compounds where the configuration itself is intricate — the sprawling automations and rule graphs that nobody can read six months later. When the logic is hard to reason about and hard to move cleanly between orgs, every release turns into a small act of archaeology before anyone can safely press deploy.

What do three releases a year cost you?

Salesforce ships three seasonal releases a year — Spring, Summer and Winter — on a published release calendar (as of June 2026). Roughly every four months your automations, integrations and managed packages meet a platform version they have never run against. Regression testing isn't a nice-to-have here; it is a standing tax you pay three times a year on every customisation you have accumulated, whether or not you changed anything yourself. Managed packages may need vendor recertification, integrations need contract re-testing, and any Apex leaning on undocumented behaviour is one release note away from breaking.

The more you have built on the platform, the larger that recurring bill — the same enterprise-rigidity pattern visible in packaged products, the kind we traced through enterprise loyalty reviews, where flexibility and upgrade safety keep pulling against each other. On-platform you don't get to opt out of the schedule; you only get to decide how much surface area you expose to it.

The direction out is not a secret: stop treating deployment as a platform feature and treat it as engineering. Source-controlled metadata, scripted and repeatable environment builds, configuration data managed as versioned artifacts rather than click-through steps, and regression suites that run on the vendor's release schedule instead of reacting to it. On the platforms we build at BrewOS, that release discipline is part of the event-driven architecture from the start rather than something bolted on after the first bad deploy.

None of these limits are hidden and none of them resolve on their own — they are the cost of doing change control inside a system optimised for configuration speed. The teams that ship calmly over the next few years will be the ones deciding now which parts of route-to-market genuinely belong on-platform and which deserve a deployment pipeline they actually control, before the next 29-day clock starts ticking.