Tools
Tools is a Setup section that provides access to various developer and administrator tools within Salesforce, including the Developer Console, debug log viewers, deployment tools, and other utilities that assist with building, testing, and troubleshooting customizations.
Definition
Tools is a Setup section that provides access to various developer and administrator tools within Salesforce, including the Developer Console, debug log viewers, deployment tools, and other utilities that assist with building, testing, and troubleshooting customizations.
In plain English
“Here's a simple way to think about it: Tools is the section of Setup where everything a Salesforce developer touches lives - Apex Classes, Triggers, Visualforce pages, Lightning Components, Static Resources, the Developer Console. Click-tool admins rarely visit; pro-code teams live here.”
Worked example
A developer at OrbitTech navigates to the Tools section in Setup to access the Developer Console for real-time Apex debugging, the deployment status page to monitor an ongoing metadata deployment, and the Apex test execution page to run the full test suite before deploying new code to production.
Why Tools matters
Tools in Salesforce Setup is the umbrella node for the developer surfaces - Apex Classes, Apex Triggers, Visualforce Pages, Lightning Components (Aura and LWC), Static Resources, Email Templates that include code, the Developer Console, and Custom Settings. Each is its own Setup page with its own permissions; the Tools node simply groups them so a developer onboarding to an org can locate the code-touching surfaces from a single Setup tree branch instead of hunting individually.
The reason this grouping matters in practice is access boundary. Many admin Profiles have Read access to Setup but no access under Tools - which means an admin can see that Apex Classes exist without being able to read or modify them. When that boundary moves (a junior dev gets Apex View permission, for example), the change shows up at the Tools-node level in the Profile, not on every individual sub-page. Audit Profile and Permission Set assignments at this grouping level when a developer joins or leaves the team.
How organizations use Tools
After hiring two integration engineers, the org's admin opened Tools in Setup and assigned them a Permission Set granting access to Apex Classes, Triggers, and Static Resources only - explicitly excluding Email Templates (where embedded code can reach customers). The Tools node was the natural unit for that scoped grant.
Use the Tools tree as the org's onboarding map for new developers - every new dev gets a one-page tour of which sub-pages they will and won't use. The Visualforce page (deprecated in their org), the Apex Class page (primary surface), the Lightning Components page (active development), and the Static Resources page (libraries, fonts, brand assets) each have a one-line description in the runbook.
Locked down Tools access via Permission Sets - only the four-person platform team has any sub-page access; everyone else's Profile is configured with Tools as a closed branch. The boundary surfaces cleanly in Setup audit history and matches the company's segregation-of-duties policy.
Test your knowledge
Q1. What skill set is typically needed to work with Tools?
Q2. What is a Governor Limit in the context of Tools?
Q3. Where would a developer typically work with Tools?
Discussion
Loading discussion…