Apex Settings
Apex Settings is the Salesforce Setup page that controls org-wide behavior of the Apex runtime.
Definition
Apex Settings is the Salesforce Setup page that controls org-wide behavior of the Apex runtime. It governs how the compiler treats deployments, whether unit tests run in parallel, how callout response limits and security defaults apply, and a handful of other knobs that shape deployment timing, test reliability, and the diagnostic data available when something breaks. You reach it at Setup, then Custom Code, then Apex Settings.
The page is low-traffic day to day, but the toggles on it carry weight. Turning on Compile All Apex on Deploy adds minutes to every deploy and catches dependency problems earlier. Disabling parallel testing slows the whole suite for every developer. The settings are also captured as the ApexSettings metadata type, so they travel between sandboxes and production through change sets or Salesforce DX. That is why two orgs that started identical can quietly drift apart over the years.
The toggles on the page and what each one changes
Where the page lives and what it controls
Apex Settings sits under Setup, Custom Code, Apex Settings. It is an org-level configuration page, not a per-user one, so anything you change here applies to every developer and every deployment in that org. The page exposes a short list of checkboxes and one or two numeric fields rather than a sprawling form. Each control maps to a field on the ApexSettings metadata type, which is how the page state moves between environments during release management. Because the settings are global, the page rewards a careful read before you flip anything. A toggle that helps one team can slow another. Compile All Apex on Deploy is worth the time on a production org, while a developer sandbox used for quick spikes might skip it. The numeric callout response limit only matters to orgs that pull large payloads from external systems. Treat the page as a place you visit deliberately during a release review, confirm the values match your standards, then leave alone. Most large orgs adjust two or three defaults to fit their practices and never touch the rest.
Compile All Apex on Deploy
By default, a deployment only recompiles the Apex classes that changed. With Compile All Apex on Deploy enabled, every class in the org compiles as part of the deploy. Salesforce documents this as Compile on Deploy in the developer guide, where it explains that the compiler runs at deploy time and saves the resulting bytecode. The tradeoff is a small increase in deployment time in exchange for catching dependency conflicts that incremental compile would miss. The setting also fixes a subtler problem. Without it, a deploy, install, or package upgrade can leave the org holding invalidated bytecode. The next time that code runs, the platform recompiles it on first execution, which produces a one-time performance hit for whoever triggers it. Pre-compiling at deploy time moves that cost into the release window instead of onto a user. Most production-grade orgs leave this on. The official deployment best-practice guidance is to turn Compile on Deploy on in a staging org so it mirrors how production will behave during the real deploy.
Disable parallel Apex testing
Apex tests run in parallel by default. The platform executes multiple test classes at once to finish the suite faster. Parallel runs can produce flaky failures when two tests touch the same shared data at the same moment, for example a common profile record or a counter that several tests update. Those failures look like UNABLE_TO_LOCK_ROW errors and are frustrating precisely because they are intermittent. The Disable Parallel Apex Testing toggle forces every test to run serially. It removes the lock-contention failures, but it slows the suite for everyone, which directly affects CI/CD timing. Salesforce recommends a more surgical fix first. From API version 24.0 onward you can annotate a specific class with isTest(isParallel=false) to opt that one class out of parallel execution while the rest of the suite keeps running concurrently. Reach for the org-wide toggle only when scattered isolation problems make the per-class approach impractical. Disabling parallelism org-wide hides the underlying data conflict rather than fixing it, so use it as a stopgap, not a permanent answer.
Sensitive data and security defaults
Apex Settings is also where a few security-related defaults live. The page controls options that affect how the platform handles potentially sensitive information and how strictly certain Apex behaviors are enforced. These are the settings you least want to weaken casually, because loosening them often shows up later in a Salesforce Security Review or an internal audit. A common one is whether the org redacts sensitive patterns from logs and output. Leaving that protection in place is cheap insurance against a credit card number or similar value landing in a developer log where it should not be. Turning it off to quiet noisy logs is the kind of decision that is hard to defend after the fact. Other toggles on or near this page tighten constructor and class behavior so that managed package code and platform features behave predictably. Treat changes in this group as deliberate, documented decisions. If you cannot write down why a security default was weakened, the safer move is to leave it at the Salesforce-recommended value and solve the original problem another way.
The callout response size limit
Apex HTTP callouts have a maximum response size. The platform caps a synchronous callout response at 6 MB, and an asynchronous one at 12 MB, as documented in the Apex callout limits reference. When a response exceeds the ceiling, the call fails with a CalloutException that reports an exceeded max size, often shown as the value 6000000 bytes for the synchronous case. That is a hard platform limit, and it is the reason large integrations sometimes break in ways that look random until you check the payload size. The Apex Settings page surfaces a related control for the callout response limit so administrators can manage it rather than leaving it implicit. The practical advice is to right-size the data first. Ask the external system to return only the fields you need, page through large result sets, or compress the payload before you treat the size limit as the problem. Pulling a multi-megabyte JSON body into Apex consumes heap, and heap is its own governed resource. Raising or relying on the maximum should be the last lever you pull, after the integration itself has been trimmed.
ApexSettings metadata and deployment drift
Every value on the page is captured by the ApexSettings metadata type, which extends the base Metadata type in the Metadata API. Because it is metadata, change sets and Salesforce DX both carry it. When you deploy ApexSettings from a sandbox to production, the platform applies the settings record, which can quietly overwrite values an admin set directly in production. This is the mechanism behind silent configuration drift. One admin flips a toggle in a sandbox. A later refresh or deployment moves that sandbox state into another environment. Now two orgs that began the same way hold different defaults, and nobody notices until a deploy behaves unexpectedly or a test suite suddenly runs differently. The fix is to treat Apex Settings as managed configuration, not a place you click into ad hoc. Keep the ApexSettings file in source control, review it during release management the same way you review code, and let the metadata be the audit trail. The Setup page shows the current state, but the metadata file is the durable record of what the org is supposed to be.
A practical worked example
Imagine a team whose nightly CI run started failing about one time in five. The failures were always lock errors, never the same test twice. A developer opened Apex Settings and saw that parallel testing was on, which is the default. The quick instinct was to disable parallel testing org-wide and move on. That would have worked, but it would have added several minutes to every run and masked the real issue. Instead the team found the two test classes that both inserted records against the same shared profile. They added isTest(isParallel=false) to just those classes and left the rest of the suite parallel. The flaky failures stopped and the suite stayed fast. During the same review they confirmed Compile All Apex on Deploy was on for production, checked that the sensitive-data protection had not been disabled, and committed the ApexSettings metadata to source control so the next sandbox refresh would not silently undo any of it. That sequence, diagnose then target then record, is how the page is meant to be used.
How to review and configure Apex Settings
Apex Settings is configured from Setup, not from code, though the resulting state can also be deployed as ApexSettings metadata. Here is the basic flow for reviewing and adjusting it. You need the Author Apex permission or equivalent admin access.
- Open the page
From Setup, type Apex in the Quick Find box and choose Apex Settings under Custom Code. Read the current state of every toggle before changing anything, since each one is org-wide.
- Set deployment behavior
Turn on Compile All Apex on Deploy for production and staging orgs so deployments precompile bytecode and surface dependency conflicts during the release rather than on first run.
- Decide on test parallelism
Leave parallel testing on unless lock-contention failures are blocking your pipeline. Prefer annotating specific classes with isTest(isParallel=false) over disabling parallelism for the whole org.
- Confirm security defaults and save
Verify sensitive-data protection and other security toggles are at their recommended values, save, then commit the ApexSettings metadata to source control so the configuration is captured.
Compiles every Apex class during a deploy instead of only changed classes. Adds deploy time, catches dependency drift early, and avoids first-run recompilation.
Forces tests to run serially across the org. Removes lock-contention flakiness but slows the suite. Use a per-class isParallel annotation first where possible.
Governs the maximum Apex HTTP callout response. Synchronous callouts cap at 6 MB and asynchronous at 12 MB; right-size payloads before relying on the ceiling.
Keeps the platform redacting sensitive patterns from output. Leave enabled; disabling it tends to surface in a Security Review.
- The settings are org-wide, so a change made to fix one team's problem affects every developer and every deployment in that org.
- ApexSettings is metadata, so a sandbox-to-production deploy can silently overwrite values an admin set directly in production.
- Disabling parallel testing makes flaky lock failures disappear but hides the underlying shared-data conflict instead of fixing it.
- The 6 MB synchronous callout cap is a hard platform limit; raising related settings will not let a single response exceed the documented ceiling.
Trust & references
Cross-checked against the following references.
- Deploying Apex | Apex Developer GuideSalesforce
- ApexSettings | Metadata API Developer GuideSalesforce
Straight from the source - Salesforce's reference material on Apex Settings.
Hands-on resources to go deeper on Apex Settings.
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. Where would a developer typically work with Apex Settings?
Q2. What skill set is typically needed to work with Apex Settings?
Q3. What is required before deploying Apex Settings-related code to production?
Discussion
Loading discussion…