By Nicolae Dragu, Salesforce System Architect at Ateko
Salesforce ships hundreds of features in every release, and most developers don’t have time to read every line of the notes. That’s fine for the Marketing Cloud or Sales Cloud updates you can pick up when they become relevant. It’s less fine for Apex changes that fix things you’ve been working around for years.
Spring ’26 has three of those. None are headline features, and none made the keynote. But each one removes a category of friction that’s been adding to the technical debt pile in long-running orgs. It’s the kind of friction that’s hard to see in a single sprint and obvious when you stack five years of code reviews together.
How do you get picklist values for a specific record type in Apex?
Spring ’26 adds ConnectApi.RecordUi.getPicklistValuesByRecordType(objectApiName, recordTypeId), the first built-in way to get picklist values scoped to a specific record type.
Before this update, Schema.DescribeFieldResult.getPicklistValues() returned every value for the field, regardless of record type. Filtering for the right record type means either hardcoding lists in Apex or making a callout to the UI API, both of which add maintenance overhead and break the moment someone adds a new record type. Dependent picklists were worse: there was no clean way to get dependencies scoped to a specific record type from Apex at all.
The new method changes that. It returns the picklist values for all relevant fields on the specified record type, including any dependencies, in a single call.
What I’d recommend: refactor any code that’s hardcoding picklist values, building UI API callouts to work around the gap, or sniffing record types to filter values manually. It’s a low-risk cleanup. The payoff is largest in orgs where record types have been added or restructured since the original code shipped. There are a couple of things to look out for, however; every getPicklistValuesByRecordType call will count toward the Salesforce Platform daily API request limits and the apex class API version will have to be set to 66.0 or newer.
Why does Blob.toPdf() now match Visualforce PDF output?
As of Spring ’26, Blob.toPdf() uses the same rendering service as Visualforce PDFs, so the two methods finally produce consistent fonts and spacing.
Apex gives you two ways to generate a PDF: render a Visualforce page with PageReference.getContentAsPDF(), or call Blob.toPdf() directly on a string. Until Spring ’26, these used different rendering engines. Fonts, spacing, and layout could come out subtly different depending on which method a developer picked.
That mattered when a long-lived integration had switched between methods over time, or when one developer wrote a feature using one approach and another wrote a related feature using the other. Visual inconsistencies in client-facing PDFs are the kind of thing that gets reported as a bug six months after launch and takes longer to diagnose than to fix.
What I’d recommend: if you’ve been avoiding Blob.toPdf() because the output didn’t match your existing Visualforce PDFs, that constraint is gone. New code can use whichever method fits the use case better. Blob.toPdf() is usually simpler for one-off generation from a string, and Visualforce is still the right choice when you need template-driven layout.
Why does ApexGuru in VS Code change the workflow?
Spring ’26 brings ApexGuru, Salesforce’s AI-powered anti-pattern detection, into the Salesforce Code Analyzer for VS Code and Code Builder. It now runs as you write.
ApexGuru has been around since early 2024, but it lived inside Setup. That made it useful for after-the-fact code review and less useful while you were writing the code that produces the anti-patterns. Bringing it into Code Analyzer changes the loop: you scan as you write, not after the deploy.
It detects the patterns I covered in my earlier post on common Apex problems: DML or SOQL inside loops, redundant SOQL, expensive methods, unused methods, SOQL with negative expressions. The full supported list is in Salesforce’s documentation.
What I’d recommend: add it to your VS Code setup. Catching these patterns at write-time costs nothing. Finding them in production after a slow Apex job times out costs a lot, both in time and in client trust.
None of these will make anyone’s release-notes highlight reel. They each fix something small. But the orgs I work with weren’t broken by single big mistakes. They got tangled by years of small ones, accumulated until the codebase was hard to change without breaking things. Spring ’26 removes three of those small mistakes from the next ten years of Apex development in any org you’re maintaining.
That’s the kind of change worth refactoring for. At Ateko, we work with orgs where this kind of debt has been compounding for years and where one good refactor cycle is the difference between a maintainable system and a fragile one. If you want a hand pulling the worst of it out, get in touch.
