A Salesforce Release Notes Summary, Rethought and Adapted for Agents

Most admins don't actually read Salesforce's full release notes when a new release ships every four months. Instead, they wait for a subreddit thread to fill in what people are hitting, or a roundup blog like SalesforceBen to round up that release's items. Salesforce publishes the full notes in one batch, weeks before the release goes live, but reading that page start to finish still isn't how most admins catch up. Both community habits fill a real gap, but neither is written by Salesforce, and neither sorts items by what your specific role needs to act on before the next release lands.

Neither one was built for a second reader either: an AI coding agent that needs to know what changed in the current release before it writes code or config against it, not a person skimming a summary at their desk. A release note is plain text and a forum thread is a wall of comments; neither is something an agent can query as structured data and trust to be current. That's the specific gap the rest of this closes, for both readers.

ForceNotes rebuilds the release summary around both of those readers, in three pieces. First, a role- and action-sorted summary lets a person read directly from Salesforce's own text. Second, the same data is queryable by an AI coding agent through MCP, machine-readable instead of scraped. Third, a tracker watches specific Salesforce Help articles for changes after the release ships, the way the MFA enforcement article below keeps getting revised since ForceNotes started watching it.

Reading a release directly, sorted by role and by what needs action

ForceNotes pulls Salesforce's release notes directly rather than starting from someone else's curation of them, then sorts every item two ways: by which roles it's actually relevant to (admin, developer, architect, consultant, analyst, business user), and by whether it's new, worth knowing, or something that needs action before enforcement. That second axis is the piece a subreddit thread or a roundup blog doesn't really give you. A generic "what's new in this release" list doesn't tell you which of those items carry a deadline for an admin specifically, as opposed to a developer or an architect. ForceNotes doesn't publish how that role and action tagging gets generated, so treat it as a fast filter for what to check first, not a replacement for reading the flagged item itself, the same caution worth applying to the tracker's AI-written diff summaries below.

ForceNotes' Winter '27 summary puts that structure to work: as of this writing (September 1, 2026), 391 items are grouped under 13 topic sections (Automation, Platform, Security, Data 360, Agentforce & Generative AI, and so on), with 58 flagged as needing action, and every item tagged by role and by new, worth knowing, or needs action. ForceNotes' stat bar separately reports 18 core topics, the fuller underlying category list. Five of those (Customization, Deployment, Development, Experience Cloud, and Mobile & Salesforce CMS) got folded into "Platform" for Winter '27 by Salesforce itself, so they show up inside that one section rather than getting their own. Expect the 391/58 numbers to have already moved by the time you read this: Salesforce keeps revising the underlying release notes, and ForceNotes keeps re-checking them.

ForceNotes covers the current release and the next one only, not a historical archive. We'll come back to what that scope catches and what it doesn't.

Two items from that summary stand out enough to name directly, independently confirmed against Salesforce's own documentation. Agentforce moves from something an admin turns on to something that's on by default: Salesforce is auto-enabling the Agentforce platform on a rolling basis for every org with Agentforce access, starting September 2026, for both new and existing orgs. And a new API Catalog, per Salesforce's own developer documentation, is "a curated registry of REST API endpoints that admins can map to custom MCP tools through the Setup UI," bringing APIs from sources like MuleSoft, Heroku, and Apex into one place an admin can publish as a named tool.

For more depth on either, two companion pieces already cover them: the Flow and Agentforce changes missing from the mandatory Release Updates checklist are in The Salesforce Winter '27 New Features That Aren't on Your Release Updates Checklist, and the full Release Update list, item by item, is in Salesforce Winter '27 Release Notes: What Admins and Developers Need to Know. ForceNotes' summary is meant to sit upstream of both: scan the role tag for what's flagged, then click through to whichever piece covers the item in depth.

The same summary, adapted for an agent to query, through MCP

Reading the summary above is still built for a human: open the site, find your role's section, read it. The same underlying data is also built for the second reader from the opening: ForceNotes runs an MCP (Model Context Protocol, Anthropic's standard for connecting AI clients to external tools and data) server so an AI coding agent can pull the release data directly, in place of an agent's training data (which has a cutoff behind the current release by definition) or a half-remembered detail from a thread or a roundup you read weeks ago.

We've written before about what Salesforce's own Hosted MCP Servers are for: letting an AI client reach into a system's data and tools through one standard connection instead of a custom integration per pairing. ForceNotes runs its own MCP server on the same idea, scoped to release tracking specifically.

The endpoint is https://forcenotes.app/mcp, plain HTTP POST using JSON-RPC 2.0, no signup and no API key. Client setup is a few lines of config:

{

"mcpServers": {

"forcenotes": {

"type": "http",

"url": "https://forcenotes.app/mcp"

}

}

}

ForceNotes exposes exactly one MCP tool, get_release_summary, capped so a query can't flood an agent's context window with the entire release. Point Claude, Cursor, ChatGPT, or Codex at the endpoint and ask it directly: "summarize Winter '27," or "what needs action before the next release."

Called with no arguments, it returns the catalog of releases ForceNotes has summarized. Called with a release name (or next / current / preview), it returns that release's overview, its items grouped by topic, and the deadline-sorted list of what needs action, each item carrying a source URL and a freshness flag so the agent (and you) can tell a same-day item from a stale one.

That one tool covers the release-notes side only: the Knowledge article tracker below isn't exposed through MCP yet, so an agent can query what changed in a release but not what changed in a Help article you're tracking. ForceNotes also publishes a downloadable Claude Skill file at forcenotes.app/skill.md, meant to be dropped into a Claude Code project so the assistant knows to reach for the tool without being told each time.

The MCP server is labeled beta: the response shape can still change, and coverage is limited to whichever releases ForceNotes has already summarized. That means it's not a fit yet for wiring an agent to a release ForceNotes hasn't covered.

Calls are also rate limited: 20 a minute and 500 a day, tracked per caller even though there's no signup step (presumably by caller IP, since ForceNotes' developer docs don't spell out the mechanism). That makes it built for targeted queries, not for scraping the whole release into a local copy.

On the privacy side, ForceNotes states it uses one strictly necessary cookie for bot protection, and that analytics is off by default, only loading if a visitor opts in. That's worth knowing if your organization's security review cares about that before anyone points a client at an external MCP endpoint.

Tracking what changes in Salesforce Help after the release ships, starting with MFA enforcement

There's a third layer on top of reading the release and querying it: watching what happens to the underlying Salesforce Help documentation after the release ships. Salesforce keeps editing those pages long after launch, and there's no changelog and no notification when a deadline moves, a section gets rewritten, or guidance gets pulled entirely. The only way to catch it is to go back and read the same page again, and nobody's job is to do that on a recurring basis.

The clearest example live on ForceNotes' own site right now is the Help article on mandatory MFA enforcement for employee users: ForceNotes has logged 30 revisions to that single article as of this writing, and counting. That's not a policy announcement sitting still. It's a page Salesforce keeps rewriting, and an admin who read it once, when MFA enforcement was first announced, and never went back, is working from a stale version of guidance that's core to their org's login security.

The MFA article isn't the only one making this case, and the second example shows why daily checking specifically matters, not just checking at all. Two separate tracked articles on Salesforce's Connected App usage restrictions both show the same pattern: a full restoration of real content on August 26, then a complete wipe back to placeholder text ("Modal Body...") the very next day, August 27, wiping out the migration timeline, FAQ, and technical guidance that had briefly been restored. Both are still sitting on that placeholder text. A tracker checking weekly would have missed that round trip entirely; an admin who happened to read the page on August 26 and bookmarked it as current would be working from a version that no longer exists, with no way to know that from the page itself. Neither of these is the kind of change a one-time read catches, and neither would show up in a tracker if nobody had thought to add it first.

That's what the tracker is built to catch: ForceNotes' Knowledge article tracker lets you add any Salesforce Knowledge article URL, and it's re-checked on a schedule, with an AI-written summary of what was added, removed, or reworded on each pass. Coverage is opt-in, though: the tracker only watches articles you've actually added to it, so it's only as good as what you remember to point it at. The straightforward way to build that list is to work backward from the release summary above: add the source article behind any item your Winter '27 summary flags as needing action, so the two halves of ForceNotes stay pointed at the same things you're on the hook for, instead of asking you to guess in advance which article matters.

Checking the tracker page yourself still means remembering to check it. ForceNotes' subscribe page closes that gap with email alerts, but the two sides carry different scope into that subscription. The release-notes side is covered automatically once you subscribe: the full 391-item Winter '27 catalog and whatever comes after it, no opt-in step required. The Knowledge article side isn't: subscribing only alerts on articles already added to the tracker, the same opt-in scope as the tracker itself, so what subscribing adds there is just not having to remember to check the page yourself.

You pick what's worth an email from four categories, in any combination: breaking changes and retirements ("anything Salesforce is removing or forcing"), enforced release updates ("release updates with an enforcement date"), silent edits ("articles edited with no entry in their own change log"), and every non-cosmetic revision to a tracked article. Silent edits is the category built for exactly the MFA article's wording swap described above. If you're accountable for a small, specific list of articles like the two examples here, every non-cosmetic revision plus a daily cadence is the combination that catches all of it, at the cost of more email.

You also choose a cadence (daily or weekly digest) and a minimum severity: everything, medium and high only, or high only. A quiet day sends nothing, so there's no filler email just to confirm the system is still running. On the privacy side, ForceNotes says it stores your email address, the category and cadence choices you made, and a one-way hash of your IP as proof of consent, nothing else, never shared or sold.

What this doesn't replace

That's one limit you control by what you add. Here's one you don't: the current-and-next-release scope is a hard boundary, not just a convenience. Anything further out drops off ForceNotes' radar.

The retirement of the OAuth 2.0 Username-Password Flow shows why that boundary matters. It was first announced in Spring '26, circulated for months as a Winter '27 enforcement deadline, and then Salesforce moved the actual enforcement date to February 20, 2027, well into a later cycle. Salesforce's own release note text now reads: "Salesforce enforces this update on February 20, 2027. This update was first announced in Spring '26. It was originally scheduled to be enforced with the Winter '27 major release, but we changed the enforcement date." A tracker that only carries the current and next release forward would already have dropped that item from its window by the time the date moved. That's exactly why ForceNotes is built to catch what's coming in the two releases ahead of you, not to stand watch over everything that shipped three or four cycles back.

Even inside that window, a summary layer is still a second-hand read. For anything with a deadline attached to it, the source URL ForceNotes attaches to each item exists for a reason: click through and read Salesforce's own current text before you act on it. ForceNotes' value here is catching the change and pointing you at it, not standing in for the original.

ForceNotes only covers the release-notes and documentation side of a release. Who has access to what afterward is a separate problem; Power User Toolkit's audit tools cover that side, if that's a gap you're also closing.

Reading Salesforce's own release text sorted by role, querying it from an agent instead of stale training data, and knowing when the underlying Help article changes are three different jobs, covered here by one tool instead of a wait for someone else's roundup. Try ForceNotes directly or go straight to the MCP setup covered above.