Skip to content

Hands-On With Salesforce Code Builder

After a long wait, Code Builder is finally here! Well, in beta, with a monthly usage cap. But, I’m excited to kick the tires and see how this will change our development flow.

Code Builder leverages VS Code for the Web, extending customized plugins through a managed package to embed VS Code within your Salesforce org.

I have customized my editor and terminal over the years, so it’s hard for me to shift to an online workflow. But, after tinkering with Code Builder, I can say definitively that this is a paradigm shift in how we will interact with our environment.

Code Builder allows us to edit our environment within Salesforce and work on any device, regardless if we’ve set up our local environment.


Code Builder comes as a managed package and will need to be installed into your Salesforce org. As always, it’s recommended to install in a Sandbox first to test and ensure there’s no interference with your production org.

Be sure to check with your security team to ensure they’re okay with third-party access to your environment. Although, it is access to Microsoft’s services.

Permission Set

Code Builder comes with its own Permission Set as part of the managed package. The Permission Set provides access to the Code Builder App and two Apex Classes.

Assign to your users and launch the app.


Code Builder will walk you through the steps needed to configure. You have the option to create a new project or import from Github.

Since my org is under source control, I imported our repo to see what it looks like in browser as compared to my local repo.

It’s recommended to connect to a Dev Hub, but since I’m testing I decided to connect only to a sandbox to ensure it’s loosely coupled to my orgs.

We Wait

The environment takes some a few minutes to setup and import your project.

It’s important to note here that your time limit decrements anytime that you’re in the Code Builder application. So I recommend navigating to another application while it is finishing its setup.

I learned the hard way when I saw that I lost six minutes of eligible time.

I am not sure if it’s a bug or not – it’s still a beta – but I had to connect to my DevHub in order to get an environment to launch. When I attempted to create an environment connected to a Sandbox, it seemed to timeout.


I have to say, having VS Code’s online developer experience directly within Salesforce is a game changer. Most often I resort to the Developer Console when I’m “in app” to test or make small tweaks.

Yes I know, VS Code and my trusty terminal are on my second virtual desktop. But, there’s something that seems so easy about being able to launch the Dev Console from within the UI.

With Code Builder, I see my reliance on Dev Console waning.


Code Builder launches with a blinding white screen, reminding me how much I have customized my VS Code theme over the years.

I quickly dive into the tour to see what is possible within the UI.

I learn that all of my VS Code shortcuts and the pallet are the same, there’s no learning curve here.

But, I do learn that it’s not full customizable. I am limited by what themes I can use (default only), and only Salesforce Extensions. None of my favorite JavaScript extensions are allowed.

I have a feeling this will relax over time as we get out of Beta.

Developer Tools

I fired up a blank project and create a scaffolded Trigger. The experience is the same as the desktop.

I can use the pallet or right click on the file to deploy to my org.

The same experience for writing SOQL queries is present. This will definitely be a game changer for testing queries or running quick analysis.


Code Builder is worth the wait. I am hoping that Salesforce will decide to not make this a paid SKU and release it from Beta soon.

Code Builder will change the way my team works, and I can see Admins being less intimidated by VS Code. This plus the focus on DevOps will introduce more Admins to how metadata is structured in Salesforce and allow them to pair with Developers more frequently.

My other hope is that we will see customizations enter the forefront and synchronize our settings with Github (or another profile service), to allow us to work across different organizations.

I hope that Code Builder will continue to grow, especially in the realm of Debug Logs. Having VS Code’s power to parse Debug Logs will make Code Builder the number one tool. This has the potential to replace Workbench and the Developer Console.

Leave a Reply

Your email address will not be published. Required fields are marked *