Salesforce Articles: Releases, Migrations, and Production Lessons
Timely Salesforce analysis for release changes, migrations, platform limits, and the production lessons that rarely fit in the announcement.
Each article here takes one Salesforce change, one capability, or one production problem, and follows it to the end. What changed, what it means once you are past the announcement, where the limits sit, and what to do about it.
These are not release note summaries. Salesforce publishes those already and they are accurate as far as they go. What they will not tell you is whether a new capability is worth adopting, what it costs to run once it is in, or which parts are still pilot and should not be designed around yet. That judgement is what these articles are for.
The difference between an article and a guide here is not depth, it is scope.
🧭 How These Differ from the Guides
Section titled “🧭 How These Differ from the Guides”The guide series assumes you are learning a subject and want it in order. The Salesforce Developer Journey runs from platform fundamentals through administration and into development, and the SOQL guides build query skills from the ground up. Both are written to be read in sequence, and both get revised as the platform moves under them.
These articles assume the opposite. You already work with the platform and you have hit one specific thing. The integrations chapter of the Developer Journey teaches integration patterns in general; the SOAP login article below assumes you already have legacy authentication running in production and a 2027 deadline, and gets straight to finding it and replacing it.
The other difference is time. A guide is kept current as a matter of course. An article is tied to a moment: the release it described, the status that feature held, and how the platform behaved when it was written. Both dates appear on every article, and the section further down explains what the second one means.
📰 Every Article
Section titled “📰 Every Article”Newest first. Each card carries its publication date and, where the two differ, the date the claims were last rechecked. Anything still in pilot or beta is marked as such, because those are the ones not to design around yet.
Salesforce MCP: architecture and adoption
Summer '26 makes Agentforce an MCP client and Salesforce an MCP server. The two connection directions, the trust model, the platform boundaries, and when to choose something else. Start here before the setup guide.
Salesforce MCP: setup and release
The implementation half of the pair above. Registration and OAuth through to Gateway policies, allowlisting, testing, monitoring, and a release checklist, for either connection direction.
Filter calculated values with SOQL FORMULA()
What the Summer '26 FORMULA() pilot can do in a WHERE clause today, where it could simplify queries, and which behaviours still need hands-on validation before you rely on them.
Introducing the Salesforce Web Console
A browser-based IDE built for in-context troubleshooting, bringing debugging, log inspection, and rapid fixes together inside Salesforce rather than across three tools.
Cut custom integration code with Named Query API
Generally available in Spring '26, with the Agentforce piece still in beta. Where it replaces thin Apex REST wrappers, and how to adopt it without giving up governance.
When platform events quietly hit their delivery limit
A real incident. How delivery allocations actually work, why a single EmpApi subscriber left open in a browser tab can drain the daily quota, and how to design so it does not happen twice.🔄 How These Articles Are Kept Current
Section titled “🔄 How These Articles Are Kept Current”Release-sensitive writing goes stale in a particular way. The feature is usually still there, but its status has moved: a pilot became beta, a beta went GA, a limit was raised, a retirement date shifted. Every article states which status it described and when, so you can judge whether that still holds before acting on it.
Two dates appear on each one. The published date is when it first went up. The rechecked date means the claims were verified against current sources again, not that a typo was fixed. Where something material changed, the article says so rather than being quietly edited underneath you.
Claims about platform behaviour come from first-party Salesforce sources or from verification in an org. Where something has not been tested hands-on, the article says so instead of implying otherwise.
If you need to confirm the current position yourself, these are the sources worth checking:
Salesforce Release Notes Confirm what shipped in the current seasonal release, and whether a feature is generally available, beta, or pilot today.
Salesforce Developer Documentation Check API contracts, platform behaviour, and current limits against the technical documentation.
Salesforce Status Rule out an instance incident before assuming a production symptom comes from your own implementation.
The Editorial Policy covers sourcing, corrections, and how release-sensitive claims are handled in full.
📬 What to Do Next
Section titled “📬 What to Do Next”Want new articles as they are published? Subscribe to the JamForce RSS feed in your preferred feed reader.
If you want a structured route rather than an answer to one question, choose a Salesforce guide based on the skill, role, or decision in front of you.
Hit something in production worth writing up, or want a topic covered here? Get in touch. A fair amount of what ends up on this page started as a reader question.