We got this wrong and here is the correction

Earlier this week we published a piece telling you that ServiceNow documentation for Brazil could not be pinned to a version, and advising you to keep Brazil links out of your upgrade runbooks until a versioned path appeared. That advice was wrong. A version-pinned Brazil documentation link exists, and it existed on the day we told you it did not.

The working form is the context-sensitive help URL on servicenow.com/docs/csh, with a topicname parameter naming the page you want and a version parameter set to brazil. That request redirects to a stable permalink under servicenow.com/docs/r/, carrying an opaque identifier. The permalink renders the Brazil release notes, shows a release version of Brazil, and carries a page stamp reading Updated September 10, 2026. Our research desk confirmed that on two separate reads.

Nothing changed on ServiceNow's side between the two pieces. We tested a narrow set of URL shapes, found all of them behaving the same way, and concluded from that sample that no version-pinned link existed anywhere on the site. The sample never supported the conclusion. We are saying so plainly because a runbook author who read the first piece is sitting and waiting for something that already works.

The URL form that holds a version

The method costs one request. Ask for the context-sensitive help path with the topic name of the page you want and the version parameter set to brazil, follow the redirect, and copy the address you land on. That address lives under the docs/r/ path, and it is the string you paste into a runbook or a change record.

Version specificity here is proven rather than assumed. Setting the same version parameter to australia produces a different permalink, and that permalink serves the Australia release notes instead of the Brazil ones. Feeding the parameter a value that matches no release at all drops the request into site search rather than quietly returning the current release. The parameter is being read.

We ran the whole check twice and the two runs agreed. Live documentation moves around during a release window, so a single pass proves very little, which was as true of our original testing as it is of this correction. Our earlier work on how the ServiceNow family release cycle is documented covers why this family in particular has been hard to pin down.

The part of the original piece that still holds

The URL shapes we tested behave exactly as we described them. The legacy bundle-style path for the Brazil release notes redirects to the documentation root and serves nothing release-specific at all. The path-style versioned addresses drop their version segment and resolve to the unversioned current-release equivalents, returning a clean page and an HTTP 200 the whole way through.

The risk we described is real too, and we would write that part again. A link captured from a current-release path follows whichever family is current on the day somebody opens it. Once the next family moves in, that same address serves a different release, and the page it serves looks entirely healthy. A broken link gets noticed. A correct-looking page about the wrong release gets read and believed.

What changes is the advice that follows. The answer to that risk is the version-parameter form rather than a wait for a versioned path to appear. If you already recorded Brazil links captured from the current-release path, those are still the wrong links, and now there is somewhere better to put them.

A permalink that will not tell you what it points at

The permalink has one practical drawback to plan around. The identifier in it is opaque, a run of characters with no release name and no topic name anywhere in the address. Somebody opening your runbook in eight months cannot tell by looking whether the link goes to Brazil, to Australia, or to a release that had not shipped yet.

So record the release name beside the link, on the same line. Add the page stamp the documentation itself displays, which on the Brazil release notes currently reads Updated September 10, 2026, and add the date you captured the link. Three short strings next to a URL, and the next reader can check whether the page in front of them is the page you meant.

That habit pays off across the whole reference set rather than on Brazil alone, and it matters most where change records get assembled across an ITSM estate and quoted into approvals. The reporting side of the same problem turned up in our note on the Brazil changes list and catalog ACL behaviour.

Go fix the links you already wrote down

Take fifteen minutes before your next change advisory board meeting and walk the Brazil links your team has already saved. Anything pointing at a current-release path gets replaced with the permalink the version-parameter form hands you. Any note to wait that came out of our original piece can be closed off.

One claim we will not make is that Brazil has reached general availability. It has not, and the date circulating on partner blogs and in search summaries is a community forecast rather than an announcement from ServiceNow. Keep forecast dates out of runbooks and out of the case you put to a change board. We reported on Brazil release notes arriving with a dated Early Availability label, and that label remains the firmest thing on the record.

Start with the release notes link, since that is the one most teams paste first. Request the context-sensitive help path with the version parameter set to brazil, take the permalink it redirects to, write Brazil and the page date beside it, and move to the next link on the list. Our method for reading change notes picks up from there.