Integrated Development Environment (IDE)
An Integrated Development Environment (IDE) for Salesforce is the code editor that developers use to build, debug, test, and deploy Apex classes, triggers, Lightning Web Components, Aura components, Visualforce pages, and the rest of an org's metadata.
Definition
An Integrated Development Environment (IDE) for Salesforce is the code editor that developers use to build, debug, test, and deploy Apex classes, triggers, Lightning Web Components, Aura components, Visualforce pages, and the rest of an org's metadata. The modern, officially supported choice is Visual Studio Code with the Salesforce Extension Pack, working on top of the Salesforce CLI. The same extensions also power Agentforce Vibes IDE, the browser-based environment that Salesforce launched as Code Builder.
The IDE covers the full development loop. You create a project against a Dev Hub, pull and push source between local files and an org, run Apex tests, step through failures with the Apex Replay Debugger, and deploy through the Metadata API, change sets, or a pipeline. The tooling has converged on one stack, so Salesforce documentation now defaults to VS Code and the CLI for almost every developer task. Older editors such as the Eclipse-based Force.com IDE were retired, and the in-browser Developer Console still ships with every org for quick edits.
How the Salesforce IDE stack fits together
Visual Studio Code with the Salesforce Extension Pack
Visual Studio Code is the desktop editor that Salesforce supports as the primary IDE. You do not get Salesforce features out of the box. You install the Salesforce Extension Pack from the VS Code Marketplace, and that single pack pulls in the pieces you need. It adds Apex language support with code completion and syntax highlighting, Lightning Web Component and Aura tooling, the Apex Test Runner, the Apex Replay Debugger, SOQL Builder, and tight Salesforce CLI integration. Installing the pack as a bundle matters, because Salesforce curates and version-aligns the set. Cherry-picking individual extensions can leave you with mismatched versions that break features. The pack has prerequisites. You need VS Code at version 1.90 or later, the Salesforce CLI installed, and a Java Development Kit at version 11, 17, or 21, since some Apex features run on the JDK. Once those are in place, the editor recognizes a Salesforce project, lights up the command palette with SFDX commands, and connects to your authorized orgs. Most professional Salesforce development happens here day to day.
The Salesforce CLI underneath every workflow
The Salesforce CLI, invoked as sf and formerly known as sfdx, is the engine that the IDE runs on. The VS Code extensions are largely a graphical front end over CLI calls, so understanding the CLI helps you understand what the editor is doing. The CLI handles authentication with commands like sf org login web, source operations with sf project deploy start and sf project retrieve start, and test execution with sf apex run test. It also creates scratch orgs, converts metadata between formats, generates manifests, and runs dozens of other operations. Many experienced developers mix the two. They author and debug in the editor, then drop to a terminal for batch work such as deploying a large set of components or scripting a repeatable task. Because the CLI is scriptable, it is also what continuous integration pipelines call. The Salesforce Extension Pack and Agentforce Vibes IDE both use the CLI behind the scenes, which is why keeping the CLI current is part of keeping the IDE healthy.
Agentforce Vibes IDE, the browser option
Agentforce Vibes IDE is the web-based development environment that Salesforce first shipped as Code Builder. It runs in a browser and bundles VS Code, the Salesforce extensions, and the Salesforce CLI without any local setup. You open it from the Setup menu in your org, and it authenticates and loads your metadata automatically, so there is nothing to install on your machine. Tools like Node.js, npm, and Git come preinstalled. The trade-off is the extension source. The desktop VS Code pulls from the Microsoft Marketplace, while the web edition sources extensions from the Open VSX Registry, so some add-ons available on the desktop are not available in the browser. Agentforce Vibes IDE also brings an Agentforce chat experience powered by MCP into the editor for coding assistance. It suits developers who want a ready environment on any device, who cannot install software locally, or who want a consistent setup for a team. Salesforce maintains the extension updates for you in the web version.
The Developer Console and the retired Force.com IDE
The Developer Console is the in-browser editor that ships with every Salesforce org. You reach it from the gear menu under Developer Console. It can edit and save Apex classes and triggers, execute anonymous Apex, run SOQL through the Query Editor, and inspect debug logs in the Log Inspector. It is the fastest route to a quick edit or a one-off query, and many developers keep it open for log inspection even when they author code elsewhere. What it lacks is the depth of VS Code, including modern source tracking, packaging support, and the replay debugger experience. Before this stack settled, the official IDE was the Force.com IDE, an Eclipse plug-in that served from 2010 until Salesforce retired it in 2018. Eclipse adoption among new developers had fallen off, so Salesforce moved its tooling to VS Code and the SFDX toolchain. Projects still in the old Eclipse format need to migrate to the SFDX source format, which the CLI can do with a source conversion command.
SFDX source format and project structure
Modern Salesforce projects use the SFDX source format, and the IDE assumes it. The project root holds an sfdx-project.json manifest that names your package directories and the API version. Under that, metadata is organized into folders by type, so Apex classes sit in a classes folder, triggers in triggers, Lightning Web Components in lwc, Aura bundles in aura, and custom objects in their own structure. This format is more granular than the older Metadata API format. Large XML files are decomposed into smaller pieces, which makes diffs in version control readable and merges far less painful. The format is also the foundation of modern packaging, including unlocked packages and second-generation managed packages. When you retrieve metadata from an org that is in the old format, the CLI converts it into source format for you. Because the structure is predictable, the editor can offer accurate code navigation, and the CLI can map files to the right metadata types during deploy and retrieve operations without guesswork.
Source tracking, scratch orgs, and deployment
Source tracking is what keeps your local project and your org in sync without manual diff work. Scratch orgs and source-tracked sandboxes record which metadata changed since the last pull or push. The IDE reads that tracking, so when you run a push or pull it moves only the changed components. This is the everyday rhythm of SFDX development. You create a scratch org from your Dev Hub, push your source, make changes, and pull anything you edited in the org back into your files. Production orgs are not source-tracked, so deploying there uses the traditional Metadata API model with an explicit manifest, often a package.xml, that lists what to deploy. From the IDE you can deploy with change sets for simple promotions, with the Metadata API for scripted deploys, or through DevOps Center for a managed pipeline with version control. Knowing which orgs are tracked and which are not prevents surprises, because the same deploy button behaves differently against a scratch org than against production.
Debugging and testing inside the editor
The Apex Replay Debugger brings a near-traditional debugging experience to VS Code. Instead of attaching to a live process, it replays a recorded debug log line by line. The workflow is straightforward. You set breakpoints in your Apex, enable logging, run the code that fails, then launch the replay debugger against the resulting log. From there you can step over lines, inspect variable values, and find the exact point where logic goes wrong. It works with unmanaged Apex classes, triggers, anonymous Apex, and test classes in any org, which makes it a reliable default for everyday bugs. Testing is built in too. The Apex Test Runner surfaces your test classes and methods in a sidebar, lets you run a single test or a whole class, and reports pass and fail results inline with code coverage. Agentforce Vibes IDE adds an Apex Interactive Debugger option for stepping through running code. Pairing the replay debugger with the test runner means you can reproduce a failure, watch it happen, and confirm the fix without leaving the editor.
Set up Visual Studio Code as your Salesforce IDE
Setting up the modern Salesforce IDE means preparing Visual Studio Code to work with your orgs. The steps below get you from a plain editor to a working Salesforce project on the desktop. If you prefer zero local setup, open Agentforce Vibes IDE from Setup instead, and these prerequisites are already handled for you.
- Install the prerequisites
Install Visual Studio Code at version 1.90 or later, the Salesforce CLI, and a Java Development Kit at version 11, 17, or 21. Confirm the CLI works by running sf --version in a terminal. The JDK is required because several Apex features depend on it.
- Add the Salesforce Extension Pack
Open the Extensions view in VS Code, search for the Salesforce Extension Pack, and install the bundle rather than picking extensions one by one. The pack stays version-aligned with Salesforce releases and auto-updates on the Salesforce schedule.
- Create or open a project
Use the command palette and run SFDX: Create Project, or open an existing folder that already contains an sfdx-project.json file. The editor recognizes the SFDX source format and enables Salesforce-specific commands and navigation.
- Authorize an org
Run SFDX: Authorize an Org or SFDX: Authorize a Dev Hub from the command palette and complete the browser login. Once authorized, you can deploy, retrieve, run tests, and open scratch orgs from inside the editor.
The org that deploy, retrieve, and test commands target unless you specify another. Set it per project so commands act against the right environment.
The org authorized to create and manage scratch orgs. Required before you can spin up scratch orgs for source-tracked development.
The Java runtime the Apex features use. Point the editor at a supported JDK (11, 17, or 21) if Apex language features fail to load.
The metadata API version stored in sfdx-project.json. Keep it current so newer metadata types deploy and retrieve correctly.
- Installing individual extensions instead of the full pack can leave versions mismatched and break features like the replay debugger.
- Missing or unsupported JDK is the most common reason Apex code completion and the language server fail to start.
- Production orgs are not source-tracked, so push and pull do not apply there; deploy with a manifest through the Metadata API or change sets.
- Agentforce Vibes IDE sources extensions from Open VSX, so some Microsoft Marketplace extensions you use on the desktop are unavailable in the browser.
Trust & references
Cross-checked against the following references.
Straight from the source - Salesforce's reference material on Integrated Development Environment (IDE).
- Apex Replay Debugger for VS CodeSalesforce
- Developer ConsoleSalesforce
Hands-on resources to go deeper on Integrated Development Environment (IDE).
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What's the modern Salesforce IDE?
Q2. What's the old Salesforce IDE?
Q3. Where do serious Salesforce DX workflows happen?
Discussion
Loading discussion…