ExamFinch.com My Study

Study guide

15.2 Developer Console, CLI, VS Code & Workbench

Practice this exam

Salesforce Certified Platform Developer I Exam

Track your progress as you read

Finished sections get a check mark.

1 Introduction & Exam Overview

1.1 Current Exam Facts 1.2 Blueprint Weights & Study Strategy

2 Platform Fundamentals

2.1 Multi-Tenant Architecture & Shared Resources 2.2 MVC Mapping on the Lightning Platform 2.3 Declarative vs Programmatic Decisions 2.4 Agentforce for Developers: Use Cases & Limitations

3 Data Modeling & Schema

3.1 Objects, Fields & Schema Design 3.2 Relationship Types & Implications 3.3 Schema Design Impact on Apex 3.4 Data Import & Export for Development

4 Platform Data Features

4.1 Formula Fields & Roll-Up Summaries 4.2 Core CRM Objects & Standard Schema 4.3 AppExchange Extensions & Platform Boundaries

5 Declarative Process Automation

5.1 Record-Triggered Flows & Declarative Automation 5.2 Approval Processes & Business Rules 5.3 When to Use Apex vs Declarative Tools

6 Apex Language Basics

6.1 Variables, Constants & Apex Data Types 6.2 Lists, Sets & Maps 6.3 Control Flow & Exception Handling 6.4 Classes, Interfaces & OOP Patterns

7 SOQL, SOSL & DML

7.1 SOQL Query Fundamentals 7.2 SOSL Search Fundamentals 7.3 DML Operations & Bulkification 7.4 Governor Limits & Transaction Boundaries

8 Apex Triggers & Order of Execution

8.1 Trigger Structure & Context Variables 8.2 Bulk Trigger Patterns & Best Practices 8.3 Save Order of Execution 8.4 Recursion, Cascading & Transaction Control

9 Asynchronous Apex

9.1 @future Methods 9.2 Queueable Apex 9.3 Batch Apex 9.4 Schedulable Apex & Job Orchestration

10 Security, Events & Schema Access

10.1 Sharing, FLS, CRUD & Injection Prevention 10.2 Platform Events Publish & Subscribe 10.3 Programmatic Schema Access (Describe)

11 Visualforce

11.1 Visualforce Pages & Markup 11.2 Standard, Custom Controllers & Extensions 11.3 Visualforce in Lightning Experience

12 Lightning Components

12.1 Lightning Component Framework Benefits 12.2 Aura Component Structure & Resources 12.3 Lightning Web Components Fundamentals 12.4 LWC Data Access: Wire, Imperative & Events

13 UI Composition & Apex Integration Patterns

13.1 Composing UI in Lightning Apps 13.2 UI Security, Performance & Accessibility Patterns 13.3 Apex Actions for Flow, LWC, and Agentforce

14 Apex Testing

14.1 Testing Framework & Coverage Requirements 14.2 Writing Unit Tests for Triggers & Classes 14.3 Test Data Strategies & Isolation 14.4 Executing Tests & Execute Anonymous Differences

15 Debugging & Developer Tools

15.1 Debug Logs & Monitoring 15.2 Developer Console, CLI, VS Code & Workbench 15.3 Sandboxes, Scratch Orgs & Environment Strategy

16 Deployment & Release

16.1 Change Sets & Metadata Deployment 16.2 Unlocked Packages, Metadata API & Salesforce DX 16.3 Release Readiness & Credential Maintenance

15.2 Developer Console, CLI, VS Code & Workbench

Key Takeaways Explain This Topic AI

Developer Console supports anonymous Apex, Query Editor, log viewing, tests, and checkpoints but is limited for source-driven teams and large projects

Salesforce CLI (sf / legacy sfdx) handles auth, retrieve/deploy, Apex tests, scratch orgs, and automation—core to Salesforce DX workflows

VS Code with the Salesforce Extension Pack is the standard IDE path: edit Apex/LWC, deploy/retrieve, run tests, and view logs against authorized orgs

Workbench offers browser SOQL/SOSL, REST/Bulk exploration, and metadata utilities—powerful but sensitive because it runs with the logged-in user’s access

Choose tools by job: quick log/query in Console or Workbench; daily development in VS Code + CLI; CI/CD and scratch-org automation via CLI

Last updated: August 2026

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:

  • Feature Use
  • Execute Anonymous Run short Apex snippets in the current user’s context
  • Query Editor Run SOQL (and related query tools) and view results
  • Logs Open debug logs generated while the console session/trace is active
  • Tests Run Apex test classes/methods and view results/coverage surfaces
  • Checkpoints Capture heap variable snapshots at lines in Apex (when configured)
  • Source views Open classes/triggers/pages for quick edits in simpler orgs

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):

  • Job CLI role
  • Authorize an org Store OAuth tokens for dev/sandbox/prod (prod deploy requires care and often pipelines)
  • Create project DX project structure with sfdx-project.json , config, force-app package directories
  • Retrieve metadata Pull metadata/source from an org into local project
  • Deploy / push Send local source to a sandbox, scratch org, or packaging org
  • Run Apex tests Execute tests and obtain results/coverage for validation
  • Scratch orgs Create/delete short-lived orgs from a scratch definition file
  • Data & other plugins Import/export samples, install packages, run scripts—ecosystem dependent

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:

sf org login web (or equivalent) to authorize a sandbox/scratch org.

Retrieve or start from a Git project.

Edit Apex/LWC locally.

Deploy to the default org.

Run relevant Apex tests.

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:

Risk Reality

Data visibility SOQL in Workbench/Console returns rows your profile/permission sets/sharing allow—or more if you use a highly privileged user

Metadata power Deploy permissions + CLI can change production automation if mis-targeted

Anonymous Apex Can run DML and callouts subject to limits and CRUD/FLS only if your code enforces them —anonymous Apex is powerful and dangerous

  • Credential handling CLI org auths are secrets; protect laptops and CI secrets stores
  • Production access Many orgs forbid personal Workbench/CLI against prod without change tickets
  • Debug log PII Logs may contain field values; treat downloads as sensitive

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

  • Goal Prefer
  • Read a just-generated debug log in browser Developer Console or Setup Debug Logs
  • Execute 10 lines of anonymous Apex once Developer Console
  • Write/refactor a trigger + tests in Git VS Code + CLI
  • Deploy a project and run all local tests in CI Salesforce CLI
  • Create/delete scratch orgs from definition CLI (often launched from VS Code)
  • Ad-hoc SOQL and REST smoke test Workbench or VS Code SOQL
  • Teach/learn quickly without installing tooling Developer Console
  • Multi-file LWC + Apex feature work VS Code
  • Investigate API resource shapes Workbench REST explorer

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

Map task → tool (anonymous/log vs deploy/test vs ad-hoc API).

Know Console limits for team ALM.

Know CLI for push/pull/deploy/retrieve/test/scratch .

Know VS Code Extension Pack as the standard IDE layered on CLI.

Know Workbench for SOQL/SOSL/REST exploration.

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.