Salesforce Doesn't Fail at the Build. It Fails at the Release.

A team can build a genuinely modern Salesforce stack: Flow as the automation spine, Apex where declarative runs out of room, Agentforce on top, Data Cloud grounding it, Experience Cloud serving it. Then that same team nearly takes the org down trying to move a Flow and two classes from a sandbox to production with a change set, a shared spreadsheet, and a guarded prayer. On the Salesforce platform the build is rarely the hard part. The release is.

So the article that follows is not about how to build in any one tool. It is about the layer underneath all six of them: how change gets from a developer's sandbox to production without breaking the thing that already works. That discipline has three parts, and the Summer '26 release made each one load-bearing. First, metadata has to live in source control, not in change sets. Second, deleting something is a different and riskier operation than adding it. Third, the test suite is what proves a release is safe, and the enforcement calendar now decides what safe means.¹

Metadata is source code now

The first shift is conceptual. In a Salesforce org, a Flow, an Experience Cloud site, a profile, and a set of Apex classes are all metadata. Treating them as one-off configuration that lives only inside an org is what makes releases impossible to reason about. Treating them as source code changes every release decision you make.

Source-driven development puts the git repository in charge. Developers and admins work in scratch orgs or sandboxes, commit their changes to a shared repo, and promote from there. Version control gives you three things that a change set cannot: a complete history of who changed what and why, a review step before anything merges, and a rollback path when a release goes wrong.² The last one matters more than it sounds. A change set cannot undo itself, but a git repo can always point back at a commit that worked.

Salesforce's own tooling pushes the same direction. DevOps Center, generally available and included at no extra cost in most licenses, replaces the click-by-click change set with tracked work items and a visual pipeline. It connects to source control such as GitHub, so admins who never touch Git still get branch-based governance, and it lets a release owner bundle changes and promote them across sandbox stages with clicks instead of spreadsheets.³ The product's launch numbers are the strongest argument for it: teams that adopted it reported up to 25% lower IT costs, 30% faster deployments, and 28% higher developer productivity, and during the open beta roughly 13,000 users ran a deployment every nine minutes.³ The caveat is that source control and DevOps Center are the mechanism, not the goal. The goal is that production only ever receives changes that were reviewed, tested, and recorded.

Two consequences follow from making source the origin of truth. Everything that can travel as metadata should, which includes not just Apex but Flow, Experience Cloud, profiles, and permission sets. And changes stop being promoted by memory. When a release is a set of reviewed commits rather than a mental bundle, the question "what exactly went out on Thursday" has an answer you can read. That is the difference between a release process you can audit and one you can only hope about.

This is the sequence a build takes before it meets the release discipline, and it is worth reading as a companion before you redesign your pipeline: which Salesforce components to build first covers the order, and this piece covers the mechanism that ships them.

The API adds, but it struggles to remove

The second part of release discipline is the one most teams learn by getting burned: deleting a component is not the mirror image of adding one. The Metadata API, which every deployment tool and Salesforce itself rely on, is eager to add and change most components and reluctant to remove many of them. A vendor that lives on the API keeps a running list of the deletions it cannot automate, and the list exposes the trap.⁴

Here is a representative sample of what the API can add and change but frequently cannot remove: picklist values only go inactive, they never truly delete. Record type visibility cannot be removed through the API, and an attempt throws "Cannot delete record type through API." A Lightning page assignment attached to a profile, the override that makes a page load differently for certain users, cannot be removed either. Login IP ranges, login hours, a profile description, a custom permission granted to a profile, custom translations, and field dependencies all share the same shape: the API can write them, and in the common case it cannot delete them.⁴

The practical failure mode is a release that includes a deletion the platform refuses, so the whole deployment fails validation, and the fix is not a flag. The two supported workarounds are to remove the deletion from the feature branch and redeploy without it, or to log into the target org's Setup UI and delete the component manually, then re-run the deploy. Either way you are doing a destructive change by hand, with all the attention that deserves.⁴⁵

Because these deletions are so fiddly, they are where rollback matters most. Deployment tools such as DevOps Center can execute destructive changes, but deleting does not roll back the way an added component can. To undo a destructive change you reverse it in source control and redeploy the restored component.⁶ The cost of getting that wrong is not abstract. Independent estimates put unplanned downtime for an organization at around $9,000 per minute, which is $540,000 an hour, so a single bad delete that reaches production earns its price in a hurry.⁶

The release habit that keeps a team out of this corner is to treat deletions as first-class, plan them explicitly, and make each one safely reversible before it ships. When the enforcement wave forces retirements, this habit is the difference between retiring an old integration cleanly and discovering six months too late that the API deleted it but the metadata stayed. For the full map of where the modern stack wires its integrations, the integration seams article is the close companion to this one.

Testing is how you prove the release

Source control and careful deletion get the change braced. Testing is what proves it will not break the org when it lands. For a platform as sprawling as Salesforce, that proof splits into three floors, and each one has changed meaning under Summer '26.

The first floor is Apex unit tests, and the bar is not a suggestion. To deploy Apex to production, the org must hold at least 75% code coverage and every executed test must pass; when you run only specified tests, each deployed class must clear the 75% mark on its own.⁷ But coverage is a floor, not a strategy, and the enforcement wave raised what good coverage looks like. Since API 67.0, database operations run in user mode by default, meaning the running user's object and field permissions are enforced during code execution. Tests that assert on a system-mode view of the data will pass on a class that breaks for a normal user, which is exactly the gap the Apex v67 migration guide warns about.¹

The tool that closes that gap is System.runAs. It lets a test run as a different user, and within the runAs block that user's sharing rules and field-level permissions are enforced, no matter how the test class itself is declared.⁸ The pattern is to create a distinct test user per permission set, then assert both directions. A positive test proves that a user with the right permission set can perform the operation. A negative test proves that a user without it gets an access error, which is the less intuitive half and the one that keeps permission sets lean.⁹

Under API 67.0 this matrix stopped being optional. The user-mode default applies to test code too, so tests now run in the context of whoever executes them, and covered-but-wrong code starts throwing failures that were never seen on API 66.⁹ This is not a bug to engineer around. The honest fix is to write restricted-user scenarios that assert the visible data, and it is a genuine anti-pattern to respond by handing more permissions to the user who runs the tests, so the false positives go quiet.⁹ One practical wrinkle: every runAs call counts against the DML statement limit, so budget the number of user-context switches in your test setup rather than sprinkling them freely.⁸

The second floor is Flow. An active process or autolaunched Flow cannot deploy to production unless the org meets its flow test coverage requirement, so the same 75% instinct applies to the declarative side, not just to code.¹⁰ If your org automates heavily in Flow, that requirement is now a release gate you have to plan around, which is a good forcing function for keeping the automation surface tested.

The third floor is Agentforce, and it needs a different kind of proof because the behavior is non-deterministic. Agentforce Testing Center, enabled automatically for Agentforce customers in sandboxes, lets a team load test utterances and evaluate an agent's responses against ground truth before deploy. It scores topic classification, whether the right action sequence ran, and response quality where an LLM judge scores answers on a scale and a passing answer clears a set threshold. It can generate test cases from agent configuration or from knowledge-base content, and it imports multi-turn conversations from Agent Builder.¹¹ The limits matter for planning: a single job accepts up to 500 test cases, you can run roughly 10 jobs an hour, and you should keep batches near 20 to 30 for performance, starting around 30 to 40 across features, personas, and edge cases.¹¹

The explicitly supported test personas include authenticated users, unauthenticated users, and prompt-injection scenarios, which is a reminder that an agent's release risk is not just wrong answers but unsafe ones.¹¹ Because Agentforce behaves probabilistically, this kind of evaluation belongs in the release pipeline as a real stage, not as a manual check before go-live. For the deeper question of how to make an agent deterministic in the first place, the determinism ladder walks the build order that this testing stage then verifies.

The enforcement calendar is a release plan

The third reason release discipline matters now is that the platform itself stopped changing slowly. Summer '26 is not a feature drop, it is a posture change, and its deadlines convert into release work. Treating them as a calendar of gates reshapes what a safe release looks like in the next four quarters.

The Apex changes in API 67.0 land together as the most significant security model shift in years: database operations run in user mode by default, classes without a sharing declaration default to with sharing, and the WITH SECURITY_ENFORCED clause is removed entirely in favor of WITH USER_MODE.¹ A developer who does not read the migration guide can write Apex at API 67.0 that looks identical to the old code and behaves differently at runtime, surfacing access errors that used to be silent.¹

Beyond Apex, the integrations you already run sit on the calendar. The OAuth 2.0 username-password flow for connected apps retires in Winter '27, replaced by the web-server flow where user context matters and the client-credentials flow for server-to-server work. The Salesforce-to-Salesforce data-sharing retires in Spring '27, with different replacements depending on whether you need unified data, partner collaboration, or full middleware. And the SOAP API login() call retires in Summer '27, pushing older enterprise and middleware connectors to REST with OAuth.¹ These are fixed dates, and each one is a release event, not a checklist item you can defer until it silently stops working.

The through-line for a release planner is that none of these are flip-and-go configuration changes. They change the runtime behavior of code that already works, they retire the exact authentication your integrations depend on, and they do it on dates you can name. That is precisely why they have to be released deliberately, tested as restricted users, and scheduled against the calendar, rather than deployed at midnight because a slide deck promised a deadline.

A release discipline that holds

When the build layer and the release layer are both under control, they collapse into one repeatable rhythm. Source control owns every change. A check-only deploy validates the bundle before anything commits. A restricted-user test matrix and a Flow coverage gate prove the behavior. An Agentforce evaluation verifies the agent in the sandbox where it is enabled. Destructive changes get their own plan with a manual-delete fallback. And the enforcement calendar, not the feature wishlist, sets the go-live dates.

None of this is exotic tooling. It is the same discipline any software team already applies to code, applied to the whole Salesforce org. The reason it is worth building now is that the enforcement wave removed the option to skip it. Tests that passed on API 66 do not guarantee behavior on 67, integrations are on retirement clocks, and a single destructive change can cost six figures an hour. On a platform this customizable, the build was never the hard part. The release was, and now the platform has made that true on a schedule you can plan against.