To reflect back on this past year, I revisited release notes and asked our developer advocates for their thoughts on some of the best features of 2022. Take a second look at these improvements to see how they can make your life better as a developer working with the Salesforce Platform!

NOTE: For the sake of transparency, the criteria for our top features include: it had to be released as Generally Available (GA) in 2022 (no Beta or Pilot features), and it had to be in some way a developer-oriented feature (we’re pretty generous about this one).

New APIs following open standards

During the past year, the Pub/Sub API and the GraphQL API were both released. These new APIs present development teams with more flexibility and productivity when integrating with Salesforce. They also represent more movement forward in adopting industry standards across Salesforce development.

Pub/Sub API

Pub/Sub API

In the past, event-based integration with Salesforce required mastering different APIs and techniques. Publishing, subscribing, and introspection were all done using different APIs and technologies. When publishing an event, you had to select one of several APIs. Your client app subscribed using some CometD protocol-based library. And if you wanted to introspect the event schema, there was a special REST API to call.

Switching to the gRPC-based Pub/Sub API means that you will need a much less explicit understanding of all of these pieces of the Salesforce API landscape. By using the gRPC language/library of your choice, you’ll have access to all of these event-based services through one common set of interfaces.



Since its introduction to the world in 2015, GraphQL has changed how developers build web and mobile apps. Billing itself as an alternative to traditional REST APIs, its single-end-point, request-once-for-lots-of-different-data approach is very popular. If you’re an experienced developer in the Salesforce ecosystem and you’ve looked at this and asked yourself, “Isn’t that kind of like a SOQL query?”, you’re both right … and wrong.

In its current state, given the existence of complex SOQL, there is a fair amount of overlap with the GraphQL API, particularly with regard to querying multiple objects. But two features still on their way are mutation support and the GraphQL API LWC wire adapter. Currently, in order to perform an ad hoc query for data in LWC, an Apex class is required. Having query support through the GraphQL API wire adapter directly in LWC will remove one additional piece of complexity for retrieving data in your LWC code. And mutations (the ability to modify and delete data) will mean that using the GraphQL API has the potential to greatly simplify web and mobile apps that connect with Salesforce. Look for these features to arrive soon!

The continued march toward open standards

There’s another big benefit to the introduction of these two APIs from the standpoint of staffing Salesforce integration projects. Using industry-standard languages and protocols broadens the accessibility of the Salesforce Platform to more developers. As a developer who already knows gRPC or GraphQL, these APIs will make it easier than ever for you to ramp up to work with Salesforce.

Learn about the new Pub/Sub and GraphQL APIs

Lightning Web Security: Like Locker, only better

When we launched Lightning Components in 2014, the promise of custom UI elements without the pain of an iFrame had every Visualforce developer giddy with excitement. Then, Salesforce product security brought us all back to Earth with the reality of what it would mean for every developer (ours, yours, your AppExchange app provider’s) to have free open access to every DOM element in the Salesforce UI. And thus, Locker service was born.

An image of a bank of old lockers

[Attribution: Ananomyx, CC BY-SA 4.0 <>, via Wikimedia Commons]

Since then, developers have learned to work with it — around it — and get the most out of building custom UIs. But the UI product and engineering teams set about figuring out a better way. That way is Lightning Web Security (LWS).

Previously, the challenge was the lack of browser features. Apart from an iFrame, there was no native way to sandbox a UI element and prevent it from being compromised by other code in the DOM. One of the most exciting initiatives in the recent history of Salesforce is our active participation in the web standards process and close partnership with browser projects and vendors. Through this cooperative approach, Salesforce influences new features being introduced to web standards and eventually to browsers that support developing with Salesforce. The ShadowRealm proposal is one such feature. It adds a sandboxed, virtualized, global object which forms the foundation of LWS.

LWS makes use of this native sandboxing feature. This means that it can better balance security with usability, performance, and integration between UI components. LWS promises to bring more flexibility to your LWC work by way of more available JS libraries. There may also be performance benefits to LWS over Locker Service.

The lightning web security setting to enable the feature in your org

To enable LWS, go to Setup > Session Settings in your org. In most cases, it shouldn’t require changes to your code, but this isn’t guaranteed (whether the code is yours or from AppExchange apps). Be sure to enable it and test it in a sandbox before enabling it in production.

Learn about LWS

LWC to Aura feature parity gains

Launching a modal window using LWC, and having your LWC display a screen flow, have been two big ticket items on the path to getting Lightning Web Components to feature parity with Aura.

From the moment LWC was launched, developers have been inquiring about when there would be an LWC that provides the modal and popover features in the fashion of the <lightning:overlayLibrary/> Aura component. Well, wait no longer — you can now create components that can be used as modal overlays by having your LWC module import and extend the LightningModal JavaScript class. This is a very new feature just released in Winter ‘23.

Here is an example of a modal component using the LightningModal class:

While Flow has had a huge number of new features drop in Winter 23, I want to call out the lightning-flow base component, which allows you to show a Screen Flow from LWC. From now on, when a screen flow is the best way to solve that problem, you can make that work in LWC.

The blog posts for lightning-modal and for embedding flow in LWC just came out in December, so I won’t spend a lot of time rehashing these. But suffice it to say, having these features baked into LWC will make every developer’s life a lot easier.

Learn about these LWC improvements

The Assert class

I’m an avid mountain biker. The first time I used a remote-operated adjustable dropper seat post (usually known as a dropper post), it fundamentally changed how I rode my bike and how much enjoyment I got from going downhill. Moving between a good pedaling height and being able to have my seat out of the way of my backside and legs was the answer to a problem that I didn’t know that I had. The Assert Apex class is a bit like that.

Side-by-side examples of a remote-operated dropper seat post in extended and compressed positions.
Who knew that having three whole assert methods was limiting? I mean what else do you need, but to be able to do assert(Boolean), assertEquals(Any, Any), and assertNotEquals(Any, Any)?

It turns out quite a bit.

The Assert class brings you a whole heap of syntactic sugar in the form of new, more specific conditional evaluations that a developer can use when testing their Apex code. Say that you need to check that a variable is of a specific type. That’s covered. Want to check for a null? That’s covered, too.

And no more having to reason about how to make your assert condition come out with a specific Boolean value as every form of evaluation comes with one method that looks for a true comparison and a false comparison. For example, checking for the instance being a specific type can either be done with isInstanceOfType() or isNotInstanceOfType().

As we shared with you in a recent blog post, you can see the difference between the two ways of testing for a result.

Here’s an example of the old System.assert() method:

And here’s an example with Assert.isInstanceOfType():

Having the intent of the test in the name of the method that you’re using for the test makes things all the clearer.

There’s even a method called fail(), which throws an assert exception without having to use the did-they-mean-to-do-that technique of assertEquals(false).

And as with the previous System methods, every method is overloaded with a method signature that allows you to write your own custom message upon assertion failure.

With all of this, you will find it easier to both write Apex tests and to reason about the Apex tests that you come across in your existing codebase.

So yeah, maybe you don’t need the Assert class in the purest sense of the word … maybe I didn’t need my dropper post, either. But we’ll all be happier with them.

Learn about the Assert class

DevOps Center

Good software lifecycle management and governance can make a big difference between the success of projects, and the efficiency of teams. With Salesforce’s unique blend of code and no code, you’ll want a tool that is built for the job.

DevOps Center was designed with this broad range of application customizations in mind. It also caters to just as broad a range of skill levels. Whether you are purely about building in the Setup menu or have mastered the command line (or anything in between), DevOps Center is for you.

DevOps Center is designed to move the Salesforce ecosystem beyond Change Sets. It offers GitHub integration, pipelines, integration with development orgs (like sandboxes and scratch orgs), and a lot of other features. So, no matter what the makeup of your team is, you can reason about how you build and deploy features for Salesforce.

Learn about DevOps Center

Honorable mentions

Obviously, we released way too many features in 2022 to sum up all of them in one short blog post. And my selections are based on my own impressions and how I use Salesforce. As the team discussed which features were launched this past year, a number of others came up. The following are some that you should consider looking into if you haven’t yet done so.


Every year blesses Salesforce developers with new features and developments on the platform. The regular release of new features is one of the things that attracts many developers to work with Salesforce. What about you? What are your favorite features of 2022? If you want to share, be sure to shout it out on social media and mention us on Twitter or LinkedIn.

About the author

Peter Chittum

Peter is a developer advocate and has been focused on developer enablement for 20 years. He leads the developer advocate team for Salesforce Platform in North America and EMEA. Find him on Twitter: @pchittum.

Get the latest Salesforce Developer blog posts and podcast episodes via Slack or RSS.

Add to Slack Subscribe to RSS