Finding your Salesforce release version through Setup
Ever been caught off guard by a new button appearing or a flow suddenly behaving differently? You probably need to check your Salesforce release version. I’ve seen teams spend hours debugging a “bug” that was actually just a new feature from a weekend update. It’s a common headache, but luckily, it’s easy to fix if you know where to look.
The fastest way to get your bearings is to head straight into Setup. You aren’t looking for a big “Winter ’25” banner – although that would be nice. Instead, you’re looking for your instance ID. Here is how you do it:
- Go to Setup and type “Company Information” in the Quick Find box.
- Look for the Instance field. You’ll see something like NA45, EU17, or AP24.
- Copy that code. That is your key to unlocking the actual release name.
Now, why doesn’t Salesforce just put the name right there? Honestly, most teams get this wrong because they expect a simple label. But because Salesforce rolls out updates in waves, different instances get the new version at different times. Once you have that instance code, you can pinpoint your Salesforce release version with 100% certainty.
Checking the Salesforce release version via Salesforce Trust
So what do you do with that instance code? You head over to the Salesforce Trust site. This is the gold standard for status updates and maintenance schedules. I use this site at least once a week to make sure my clients aren’t about to hit a maintenance window during a big deployment.
Once you’re on the Trust site, click on “Status” and paste your instance code into the search bar. It will show you exactly which version is currently live on that hardware. It also shows you the upcoming schedule. If you are curious about what is coming next, you can check out my notes on the Spring ’26 release to see which features might be hitting your org soon.
One thing that trips people up: don’t just check your production org. Sandboxes often get updated weeks before production. If you’re testing new code, always verify the version in both environments first.
The developer way: Using CLI and Apex
If you’re like me and spend half your day in VS Code, you don’t want to click through the UI just to find a version number. You can grab the instance information directly from the command line. It’s much faster when you’re managing multiple scratch orgs or sandboxes.
Just run sf org display - target-org myOrgAlias (or the older sfdx version if you haven’t switched yet). Look for the “Instance URL”. If it says something like https://na123.my.salesforce.com, your instance is NA123. Easy, right?
If you’re already in the Developer Console and want a quick answer, you can run this tiny snippet of Apex in the Anonymous Window:
String host = URL.getSalesforceBaseUrl().getHost();
System.debug('Your host is: ' + host);This will spit out your full URL in the debug logs. Just grab the instance part and head back to the Trust site. It’s a handy trick when you’re already deep in a coding session and don’t want to break your flow for a Salesforce release version check.
UI clues and release updates
Sometimes you don’t even need to leave the org. If you’re still using Salesforce Classic – no judgment here, some of us still love the speed – the footer often shows the current release. In Lightning, it’s a bit more hidden. But you can always search for “Release Updates” in Setup.
This section is actually one of the most overlooked features in the platform. It doesn’t just show you the version; it tells you exactly which security and logic changes are about to become mandatory. I’ve seen many projects saved by an admin who checked this page and realized a critical update was about to break their custom integrations.
What about sandboxes?
Sandboxes are a different beast. Depending on whether your sandbox is on a “preview” instance or a “non-preview” instance, you might be running a completely different Salesforce release version than your production org. This is intentional. It gives you a few weeks to play with new features before they go live. If you’re confused about which sandbox you should be using for testing, check out this guide on Salesforce sandbox types to see how the schedules differ.
Key Takeaways
- Find your instance: Use Company Information in Setup to find your code (e.g., NA144).
- Use Trust: The Trust site is the only way to see the specific schedule for your hardware.
- CLI is faster: Use
sf org displayto get instance details without clicking through menus. - Watch the sandbox: Preview sandboxes get the Salesforce release version earlier than others.
- Check Release Updates: Always look at the Release Updates menu in Setup to see what’s coming.
The short answer? Grab your instance code from Setup and check the Trust site. It’s the most reliable method I’ve found in ten years of working on the platform. Whether you’re a developer trying to use a new Apex class or an admin planning your next training session, knowing exactly where your org stands saves a lot of frustration. Give it a shot next time you notice something “weird” happening in your org – it’s usually just a new release making itself at home.








Leave a Reply