15.2 Developer Console, CLI, VS Code & Workbench

15.2 Developer Console, CLI, VS Code & Workbench

Quick Answer: Use Developer Console for quick anonymous Apex, queries, tests, and logs in the browser. Use Salesforce CLI (sf / legacy sfdx) for retrieve, deploy, test, and org automation. Use VS Code + Salesforce Extension Pack as the primary IDE. Use Workbench for ad-hoc SOQL/SOSL/REST against an org—always respecting that tools run with your user permissions. Match the tool to the task; do not treat Console as a full ALM platform.

Platform Developer I is not only about writing Apex—it is about working effectively (and safely) in Salesforce developer tooling. Exam scenarios often describe a goal (run a query, deploy metadata, inspect a log) and ask which tool fits.

Developer Console

The Developer Console is a browser-based workbench available from the Salesforce UI (App Launcher / Setup context depending on org). Core capabilities:

Strengths: No local install, fast for support engineers, great for reading a log you just generated, handy anonymous Apex for one-off data fixes in sandboxes (with change control!).

Limits (exam-relevant):

• Weak fit for source-driven development, branching, and code review.
• Awkward for large Lightning Web Component front-end workflows compared to VS Code.
• Easy to make untracked changes directly in an org if discipline is low.
• Not the center of modern CI/CD; teams standardize on CLI + Git instead.
• Session and org performance constraints make it a companion tool, not the enterprise IDE.

If a question contrasts “maintain a multi-developer unlocked package project” vs “run anonymous Apex once,” Console loses the first and wins the second.

Salesforce CLI (sf and legacy sfdx)

Salesforce CLI is the command-line interface for Salesforce DX. Historically many docs and exams referenced sfdx commands; the modern unified CLI uses the sf binary with noun-verb commands. Conceptually know both eras: same jobs—authenticate, retrieve, deploy, test, create scratch orgs.

Representative tasks (conceptual command families):

Push/pull vs deploy/retrieve: In second-generation / source-tracked scratch org workflows, developers often push/pull incremental source. Against non-tracked sandboxes, deploy/retrieve (metadata or source format) is the common pattern. The exam cares that CLI is how you move metadata and run tests outside the browser, not that you memorize every flag.

Why CLI matters for PD1 thinking:

• Enables automation (scripts, CI).
• Makes deployments repeatable versus click-click Setup changes.
• Pairs with version control as the source of truth.
• Runs Apex tests the same way pipelines will before promotion.

VS Code and the Salesforce Extension Pack

Visual Studio Code with the Salesforce Extension Pack (Apex, Lightning Web Components, Visualforce, SOQL, Salesforce CLI Integration, etc.) is the de facto desktop environment:

• Syntax highlighting, navigate-to-definition, and Apex language features
• Org browsers / manifest-based retrieve and deploy
• Embedded SOQL execution in many setups
• Test runners and coverage highlights
• LWC local development support patterns
• Log streaming/viewing integrations via CLI

Typical daily loop:

1. sf org login web (or equivalent) to authorize a sandbox/scratch org.
2. Retrieve or start from a Git project.
3. Edit Apex/LWC locally.
4. Deploy to the default org.
5. Run relevant Apex tests.
6. Inspect failures via tests + debug logs.

VS Code depends on the CLI under the hood for many operations. If CLI auth is broken, the extensions fail too—useful troubleshooting insight.

Compared to Developer Console: VS Code wins for multi-file refactors, Git diffs, and team standards. Console wins for zero-setup emergency inspection in a browser.

Workbench

Workbench (workbench.developerforce.com and related deployments) is a web tool that logs into an org via OAuth and exposes:

• SOQL and SOSL query execution
• REST API exploration (resources, methods, raw requests)
• Bulk API utilities for data movement experiments
• Metadata and session utilities useful for admins/devs
• Insert/update/delete/upsert operations when permitted

When Workbench shines: Ad-hoc data investigation, verifying sharing by running queries as a given user session, exercising REST endpoints without writing Apex, quick checks of field API names and counts.

When not to rely on it: Long-term application development, permanent integration architecture (use Named Credentials, official APIs, proper apps), or unsupervised production data edits.

Security Implications of Tool Access

Every tool above runs as the authenticated user (or as an integration user if you authorized one). That has hard consequences:

Exam framing: Tools do not bypass the platform’s security model by magic, but developers often use admin-level users, which effectively grants broad access. Principle of least privilege applies: debug with a user that matches the bug’s profile when investigating sharing; deploy with controlled integration identities in pipelines.

Also remember: with great query power comes great export risk. Bulk extract via Workbench or API tools can move sensitive data off-platform—compliance policies matter as much as Apex syntax.

When to Use Each Tool

Anti-patterns:

• Building a full app only in Developer Console with no version control.
• Using Workbench as an unofficial ETL system for production nightly loads.
• Authorizing CLI to production from an unmanaged personal machine without controls.
• Ignoring test runs and “deploying because it compiled.”

Connecting Tools to Debugging (Chapter Arc)

Section 15.1’s logs appear inside Developer Console, VS Code/CLI log commands, and Setup. Exception emails still send regardless of IDE. Event Monitoring is usually analyzed outside Console (specialized apps/APIs). Your tool choice should make the feedback loop short: change source → deploy → test → log → fix.

Exam Checklist

1. Map task → tool (anonymous/log vs deploy/test vs ad-hoc API).
2. Know Console limits for team ALM.
3. Know CLI for push/pull/deploy/retrieve/test/scratch.
4. Know VS Code Extension Pack as the standard IDE layered on CLI.
5. Know Workbench for SOQL/SOSL/REST exploration.
6. Always answer security: user context, deploy risk, data exposure.

If you can explain why you open VS Code instead of Workbench for a package feature—and why you open Workbench instead of writing a throwaway Visualforce page for one REST check—you are exam-ready on developer tooling.