Developer Console

Developer Console in Salesforce: Complete Guide for Platform Developer 1 Exam

Why is the Developer Console Important?

The Developer Console is one of the most essential tools in a Salesforce developer's toolkit. It serves as an integrated development environment (IDE) directly within the browser, allowing developers to write, test, debug, and optimize code without needing any external software. For the Salesforce Platform Developer 1 exam, understanding the Developer Console is critical because questions frequently test your knowledge of how to use it for writing Apex, running tests, analyzing debug logs, executing SOQL/SOSL queries, and troubleshooting issues.

What is the Developer Console?

The Developer Console is a browser-based IDE provided by Salesforce that gives developers access to a collection of tools for creating, debugging, and testing applications in their Salesforce org. It can be accessed by clicking on your name (or the gear icon in Lightning Experience) and selecting Developer Console.

Key capabilities of the Developer Console include:

• Source Code Editor: Write and edit Apex classes, Apex triggers, Visualforce pages, Visualforce components, Lightning components (Aura), and static resources.
• Log Inspector: View and analyze debug logs in detail using different panels such as the Execution Overview, Stack Tree, Execution Stack, and Timeline views.
• Query Editor: Execute SOQL (Salesforce Object Query Language) and SOSL (Salesforce Object Search Language) queries and view the results inline.
• Anonymous Execute Window (Execute Anonymous): Run snippets of Apex code on the fly without saving them as part of your org's codebase.
• Test Runner: Run unit tests individually, by class, or as a full suite, and view code coverage results.
• Checkpoint and Heap Dump Inspector: Set checkpoints in your code to capture heap dump information at specific execution points for advanced debugging.
• Navigation and File Management: Open, search, and manage your org's metadata files.

How Does the Developer Console Work?

The Developer Console operates entirely within your web browser and connects directly to your Salesforce org. Here is how its major features work:

1. Opening the Developer Console
In Salesforce Classic, click your name at the top right and select Developer Console. In Lightning Experience, click the gear icon and select Developer Console. It opens in a new browser window.

2. Source Code Editor
Navigate to File > New to create new Apex classes, triggers, Visualforce pages, or other resources. You can also open existing files via File > Open or by using the file navigation panel. The editor provides basic syntax highlighting and auto-save capabilities. Each file opens in its own tab within the console.

3. Execute Anonymous Window
Access this via Debug > Open Execute Anonymous Window (or the shortcut Ctrl+E). This allows you to write and execute Apex code that is not saved to the org. It is commonly used for:
- Quick testing of logic
- Running DML operations (insert, update, delete records)
- Debugging specific scenarios
- Calling methods from existing classes

The results and any System.debug() output appear in the debug log.

4. Query Editor
Located at the bottom of the Developer Console, the Query Editor tab lets you write and execute SOQL and SOSL queries. You can toggle between SOQL and SOSL using the Use Tooling API checkbox. Results are displayed in a tabular format, and you can even edit records directly from the results grid (for SOQL queries).

5. Debug Logs and Log Inspector
Debug logs capture the execution details of transactions in your org. You can configure log levels via Debug > Change Log Levels. Log levels can be set for different categories:
- Database: DML and SOQL operations
- Workflow: Workflow rules and processes
- Validation: Validation rules and formulas
- Callout: External web service callouts
- Apex Code: Apex code execution
- Apex Profiling: Cumulative resource usage and limits
- Visualforce: Visualforce events
- System: System-level events

Each category can be set to levels: NONE, ERROR, WARN, INFO, DEBUG, FINE, FINER, FINEST. Higher levels capture more detail but produce larger log files. Remember that debug logs have a maximum size of 20 MB. Logs that exceed this limit are truncated.

The Log Inspector provides multiple views to analyze logs:
- Stack Tree: Shows the call hierarchy
- Execution Stack: Shows the current stack frame
- Execution Log: Shows the raw log entries with timestamps
- Source: Highlights the source code being executed
- Executed Units: Shows performance metrics per unit (class, trigger, etc.)
- Limits: Displays governor limit consumption
- Timeline: A visual representation of the execution timeline

6. Running Tests
Navigate to Test > New Run to execute test classes. You can select specific test classes or individual test methods. After execution, the Test tab displays:
- Pass/fail status for each test method
- Error messages and stack traces for failures
- Code coverage percentages per class and overall
- The ability to drill into specific lines covered or not covered

You can also run all tests in the org using Test > Run All, though this is typically used less frequently due to time constraints.

7. Checkpoints
Checkpoints allow you to capture the state of the heap at a specific line of code during execution. You can set up to 5 checkpoints at a time, and they persist for 30 minutes before expiring. Checkpoints capture variable values, object states, and memory usage at the exact point in execution, making them invaluable for complex debugging scenarios. Set checkpoints by clicking in the margin next to a line number in the source code editor and then selecting Debug > Checkpoints.

8. Workspace Management
The Developer Console uses workspaces to organize your open tabs and panels. You can create, switch, and manage workspaces via Workspace > New Workspace. This is useful for organizing different sets of files for different projects or tasks.

Key Limitations of the Developer Console

- It does not support Lightning Web Component (LWC) development. LWC development requires Salesforce CLI and VS Code with Salesforce Extensions.
- Debug logs are capped at 20 MB; larger logs get truncated.
- A maximum of 5 checkpoints can be active at one time.
- Checkpoints expire after 30 minutes.
- The console retains up to 20 debug logs at a time in the Logs tab (older logs are available via the Logs list but roll off the active view).
- It is browser-based, so performance can be affected by browser memory and network speed.
- The Developer Console does not provide version control or team collaboration features.

Developer Console vs. Other Tools

- VS Code with Salesforce Extensions: More powerful, supports LWC, has Git integration, better for team development. However, requires local setup.
- Setup Menu (Apex Classes page): Can be used to create/edit Apex classes but lacks debugging and testing features.
- Workbench: Third-party tool useful for SOQL queries and REST API testing, but not a full IDE.

For the exam, know that the Developer Console is Salesforce's built-in browser-based IDE and understand when it is the appropriate tool to use versus alternatives.

Common Use Cases Tested in the Exam

1. Debugging an issue: Use debug logs and the Log Inspector to trace execution and find errors.
2. Running a quick piece of code: Use the Execute Anonymous window.
3. Querying data: Use the Query Editor for SOQL/SOSL.
4. Running unit tests and checking coverage: Use the Test menu to run tests and review code coverage.
5. Setting log levels: Adjust log level categories and their detail levels to control what information is captured.
6. Viewing governor limit usage: Use the Limits perspective in the Log Inspector.

---

Exam Tips: Answering Questions on Developer Console

1. Know the access path: Questions may ask how to open the Developer Console. Remember it is accessed from the Quick Access menu (your name or gear icon), not from Setup.

2. Execute Anonymous is not saved: Code run in the Execute Anonymous window is not saved as part of your org metadata. It executes in the context of the running user and respects all governor limits. Understand that DML operations performed here are committed to the database unless an exception occurs or you explicitly use Database.rollback().

3. Debug log levels matter: If a question describes a scenario where debug logs are missing information, consider whether the log level is set too low for the relevant category. For example, if SOQL queries are not appearing, the Database category may need to be set to a higher level.

4. Remember the 20 MB log limit: If a question mentions truncated logs, the answer likely involves the log size limit. The solution is typically to reduce the log levels for categories you don't need or to narrow the scope of what you are debugging.

5. Checkpoints vs. System.debug(): Understand the difference. System.debug() writes to the debug log and is a code-based approach. Checkpoints capture the full heap state at a specific line without modifying code. For exam questions about inspecting variable state without changing code, checkpoints are the answer.

6. Testing knowledge is frequently tested: Know that from the Developer Console you can run individual test methods, entire test classes, or all tests. Know that code coverage results are visible in the Tests tab after execution and that you can see which lines are covered (blue) and which are not (red).

7. SOQL vs. SOSL in Query Editor: Remember that the Query Editor supports both. SOQL returns records from a single object (with related objects via relationships), while SOSL searches across multiple objects. Know the syntax differences.

8. Governor limits in logs: The Developer Console's Log Inspector includes a Limits tab that shows governor limit consumption. This is the go-to tool for identifying if your code is approaching or hitting limits.

9. No LWC support: If a question asks about developing Lightning Web Components, the Developer Console is not the correct answer. The correct tool is VS Code with Salesforce Extensions and the Salesforce CLI.

10. Perspective and Panel layouts: The Developer Console allows you to switch between different perspectives (e.g., Debug, Analysis). While the exam rarely asks about specific UI layouts, understanding that the Log Inspector has multiple panels (Timeline, Executed Units, Limits, Stack Tree, etc.) can help you answer questions about how to analyze performance or trace execution.

11. Elimination strategy: When you see questions about where to perform a specific development or debugging task, eliminate options that don't make sense. For instance, Setup > Apex Classes does not let you run tests with detailed coverage views—that's the Developer Console. Similarly, if the question is about deploying code to production, the Developer Console is not a deployment tool (deployment uses Change Sets, Metadata API, Salesforce CLI, or managed packages).

12. Understand the context of execution: Execute Anonymous runs in the current user's context, which means it respects field-level security, sharing rules, and profile permissions. However, if the class being called uses without sharing, that keyword is respected. This nuance can appear in exam questions combining Execute Anonymous with sharing/security concepts.

By mastering these concepts and tips, you will be well-prepared to handle any Developer Console-related questions on the Salesforce Platform Developer 1 certification exam.