Skip to content
SteveTechArcSteveTechArc Courses

Resilience to Releases

Module 9 of 9 in the chapter Reliability, Recovery, and Observability, chapter 14 of the Integration Architect course. Each module stands on its own. Previous: Reporting · Next chapter: Integration Orchestration

The question this module answers: How do you keep an integration working when Salesforce, and the system on the other end, keep changing underneath it?

Three Times a Year

Section titled “Three Times a Year”

When I ask a class how many times a year Salesforce releases, someone always guesses once, or four times. It’s three. Three releases a year, each with a new API version, new features, and changes to old ones. Your integration didn’t change. The platform it runs on did.

And the system on the other end changes too, on its own schedule. Redrock ships a new version of its API. The integration platform gets an upgrade. A certificate is renewed. Every one of those is a release your integration has to survive.

Chapter 13 made this point about security: “something secure yesterday may not be secure today” (chapter 13 module 1). Reliability works the same way. Something that works today may not work after the next release, unless you’ve planned for it. That’s what the exam means by building resilience to system updates.

Your Version, at the Bottom of the List

Section titled “Your Version, at the Bottom of the List”

Every call into Salesforce names an API version, and each version is a promise: it acts the same until it’s retired (chapter 3 module 2). So you pin it, on purpose, and you track it. You want your version at the bottom of Salesforce’s list of supported versions, near the newest, not at the top, near the oldest.

Because the top of the list closes. Salesforce’s current notice is specific. API versions 31.0 to 40.0, the oldest still running (“API version 31.0 was from our Spring ‘14 release”), will be “deprecated and will no longer be supported” in Summer ‘27, and “retired and removed from the platform” in Summer ‘28. After that, the calls fail with an answer you can’t miss: “REST API returns 410: GONE. SOAP API returns 500: UNSUPPORTED_API_VERSION. Bulk API returns 400: InvalidVersion” (Salesforce Help 005321531 (opens in a new tab)).

The danger is the call nobody remembers: a version number written into an external app years ago, still working, until the day it doesn’t. Chapter 8 showed how to find those callers with the API Total Usage log, and why to keep every caller’s version in the inventory (chapter 8 module 1). And remember the one thing the retirement doesn’t cover: “Custom Apex REST & SOAP Web Services.” Your own doors’ versions are yours to retire, and yours to warn people about.

Test knowledge. Know the API version retirement (BLD-6): versions 31.0 to 40.0 deprecated in Summer ‘27 and retired in Summer ‘28, after which REST returns 410 GONE, SOAP UNSUPPORTED_API_VERSION, Bulk InvalidVersion; 21.0 to 30.0 already retired in Summer ‘25; custom Apex REST and SOAP services aren’t affected. Know how to find the callers: the API Total Usage event log.

Release Updates: Changes With a Date

Section titled “Release Updates: Changes With a Date”

Some changes arrive with a due date. Salesforce lists them on the Release Updates page in Setup, “to review changes that can affect your customizations and to track the required steps.” For each one with a scheduled date, “complete the required steps before Salesforce enforces the changes” (Release Updates (opens in a new tab)).

Two lines on that page are worth reading twice. “Completing steps and recording completion are separate from Salesforce enforcement”: marking an update as done doesn’t change what happens on the enforcement date. And “For some release updates, Salesforce offers a self-service option to postpone the enforcement”: some, not all. Don’t plan on an extension.

Several of the biggest changes in this course arrived this way: the end of the username-password and user-agent flows, and the move off connected apps (chapter 13 module 6). So someone who owns the integrations reads the Release Updates page every release, and checks the inventory against it.

Test Before Production Does: the Preview Sandbox

Section titled “Test Before Production Does: the Preview Sandbox”

Salesforce gives you a head start on every release. Some sandboxes are upgraded early, and “The sandbox preview starts approximately 4-6 weeks before the production upgrade.” Trailhead’s advice is plain: “make sure you have at least ONE preview sandbox, and make sure it stays on the new release throughout the sandbox preview period” (Access Sandbox Preview for New Features (opens in a new tab)).

That’s four to six weeks to find out whether the new release breaks your integration, instead of finding out from Redrock on the Monday after. But only if the preview sandbox has the integration connected: the named credentials pointing at the partners’ test environments, the integration users, the tests ready to run. A preview sandbox with nothing connected to it can’t tell you anything about the integration.

Three Kinds of Test

Section titled “Three Kinds of Test”

So what do you run in that sandbox? An integration has two sides and a contract between them, and no single kind of test covers all three.

Three kinds of test Three kinds of test, three panels. Mocks: your code against a pretend partner; proves your code handles every answer, a 200, a 429, a 500, a strange body; fast, runs everywhere, counts for coverage; can't tell you the real call works. Contract tests: each side against the shared contract, tested on its own; proves both sides still agree on the messages; catches a change on either side before the two meet. End to end: the real path, in test environments only; proves the address, the sign-in and the real answer work; slowest, and needs every system's test environment up. Underneath: each kind of test answers a different question; an integration needs all three. {"author": "Steve Simpson", "blueprint": "1.0.0", "builder": "standard 1.58.0", "built": "2026-11-04", "id": "DGM-INT-FM-21", "rights": "\u00a9 2026 Twinshark LLC. All rights reserved.", "template": "comparison/side-by-side 0.5.0", "theme": "stevetecharc 1.4.0"} Mocks your code, a pretend partner Proves your code handles every answer. A 200, a 429, a 500, a strange body. Fast, runs anywhere, counts for coverage. Can't tell you the real call works. Contract tests each side, against the contract Proves both sides still agree on the messages. Each side is tested on its own. Catches a change before the two meet. End to end the real path, in test environments Proves the address, sign-in and answer work. The slowest, and the most fragile. Needs every test environment up. Each kind of test answers a different question. An integration needs all three. © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

Each answers a different question.

Mocks test your code against a pretend partner. Chapter 9 built them for Apex callouts: they prove your code handles every answer the partner could give, and they’re fast and run anywhere (chapter 9 module 8). What they can’t do is tell you the real call still works, because a mock answers exactly what you told it to.

Contract tests test each side against the agreement between them. In Pact’s words, a popular tool for it: “Contract testing is a technique for testing an integration point by checking each application in isolation to ensure the messages it sends or receives conform to a shared understanding that is documented in a ‘contract’.” That’s chapter 3’s contract, made testable. If Redrock renames a field, their side fails its contract test before the change ever reaches you. Pact also names the alternative honestly: “Without contract testing, the only way to ensure that applications will work correctly together is by using expensive and brittle integration tests.”

End-to-end tests run the real path: through the named credential, the sign-in, the integration layer, to the partner’s test environment and back. They prove the whole thing works. They’re also the slowest and the most fragile, and they need every system’s test environment to be up. Chapter 9 added Salesforce’s newest piece here, Apex integration tests that make a real callout from a scratch org, still a Developer Preview in Winter ‘27 (chapter 9 module 8).

You want all three, in proportion: many mocks, a contract test for every arrow that crosses to another team, and a few end-to-end tests for the paths that matter most. And every one runs on test data, never real data. A test environment with copies of real deliveries is one more place real data can leak from, for every reason in module 3.

A Release Checklist

Section titled “A Release Checklist”

Put it together. Three times a year, for Salesforce, and whenever a partner announces a release of its own:

A release checklist A release checklist, five numbered steps. 1, read the release notes and the Release Updates page: who owns each change, and its date. 2, keep a preview sandbox on the new release, connected to the partners' test environments: four to six weeks of warning. 3, run the tests there: mocks, contract tests, end to end, on test data. 4, check every caller's API version against the retirements: the inventory and the API Total Usage log. 5, highlighted, watch the first days after the upgrade: the error rate against the same day last week. Underneath: three Salesforce releases a year, and every partner's own; the checklist runs for each. {"author": "Steve Simpson", "blueprint": "1.0.0", "builder": "standard 1.58.0", "built": "2026-11-04", "id": "DGM-INT-FM-20", "rights": "\u00a9 2026 Twinshark LLC. All rights reserved.", "template": "flow/sequence 0.1.0", "theme": "stevetecharc 1.4.0"} Read the release notes and Release Updates who owns each change, and its date Some changes arrive with an enforcement date. Keep a preview sandbox, connected on the new release, wired to the partners' test environments Four to six weeks of warning. Run the tests there mocks, contract tests, end to end On test data, never real data. Check every caller's API version the inventory and the API Total Usage log Old versions retire on a date. Watch the first days after the error rate against the same day last week Whatever the tests missed, the reports catch. 1 2 3 4 5 WHY Three Salesforce releases a year, and every partner's own. The checklist runs for each. HOW TO READ IT 1 the order a step the step that matters most what comes next © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

Every release, the same five steps.

The last step closes the loop with module 8. Whatever the tests missed, the reports should catch: an error rate that’s higher than the same day last week, the morning after the upgrade, is the release talking.

Your Lab Bench: a Partner That Fails on Purpose

Section titled “Your Lab Bench: a Partner That Fails on Purpose”

Here’s a way to practise the failures without breaking anything real. Build a pretend Redrock in Postman, and make it fail on cue.

  1. Create a collection for Redrock’s webhook, with one request: POST /status.
  2. Save examples of every answer you want to test: a 200 that accepts the status; a 429 with a Retry-After header; a 500; a 200 with a body that doesn’t match the contract.
  3. Create a mock server from the collection. Postman’s mock server simulates “a real API server that’s always available to handle requests.”
  4. Ask for each failure. Send your status with the header x-mock-response-code: 429, then 500, and so on. Postman: “You can use the x-mock-response-code header in your request to specify the response status code you want.” Watch what your integration does with each one: does it wait as told, retry, park the status in the to-do list?

Two cautions. “New mock servers are public by default,” so make it private if anything about it is sensitive, and put only made-up deliveries in it. And when your mock server is answering, you’re testing your handling, not Redrock: it’s a mock, with a mock’s limits.

Beyond the exam: AI in the work. This is one of the best uses of AI in integration work. Give it the contract, and it drafts the bad payloads: the missing field, the wrong type, the extra field, the empty list, the date in the wrong format, the status that doesn’t exist (chapter 3 module 6). Ask it for the failure cases too: the 429 with a Retry-After of an hour, the timeout, the duplicate, the old status after the new one. Then save them as examples on your mock server. You review each one, because a test that’s wrong passes for the wrong reason. And give it the contract, never real payloads.

What an Architect Decides Here

Section titled “What an Architect Decides Here”
  • The API version each caller uses, pinned and written in the inventory, with the date its version retires.
  • Who reads the release notes and Release Updates every release, and checks the inventory against them.
  • A preview sandbox, connected, kept on the new release, with the partners’ test environments behind it.
  • The tests for each arrow: mocks, a contract test where another team owns the other side, end to end for the paths that matter, all on test data.
  • What’s watched in the days after each release, and what counts as “the release broke it.”
  • How each partner tells you about their releases, written into the contract.

Explore

Section titled “Explore”

Follow Me

© 2023–2026 Twinshark LLC. All rights reserved. · Content Use

Privacy notice

SteveTechArc is independent and is not affiliated with, sponsored by, or endorsed by Salesforce, Inc. Salesforce and related marks are trademarks of Salesforce, Inc.

Educational content, shared as is. Not professional, legal or financial advice. Salesforce changes several times a year, so check current Salesforce documentation before you rely on any platform detail.