Apex Settings
Apex Settings is the Salesforce Setup page that controls org-level behaviour of the Apex runtime: how the compiler handles deploys, whether parallel test execution is on, whether the org keeps a finer-grained schema cache, and how Apex governs sensitive data scanning, callout response sizes, and test framework defaults.
Definition
Apex Settings is the Salesforce Setup page that controls org-level behaviour of the Apex runtime: how the compiler handles deploys, whether parallel test execution is on, whether the org keeps a finer-grained schema cache, and how Apex governs sensitive data scanning, callout response sizes, and test framework defaults. The page lives at Setup, Custom Code, Apex Settings. It is one of the lower-traffic Setup pages day to day, but the toggles on it shape deployment behaviour, CI/CD timing, and the diagnostic information available when something goes wrong.
The settings are org-wide. Toggling Disable Parallel Apex Testing slows the whole test suite for every developer. Turning on Compile All Apex on Deploy adds time to every deployment but catches dependency mismatches earlier. Most large orgs change two or three of the defaults to match their development practices, then leave the page untouched for years. The settings are also captured in the Apex Settings metadata type so they can move between sandboxes as part of release management, which prevents the drift that produces deployment surprises after a sandbox refresh.
The settings that actually shape Apex behaviour in production
Compile All Apex on Deploy
Without this setting, Salesforce only recompiles the Apex classes that changed in a deploy. With it, every class compiles. Compile All Apex is slower on deploy but catches dependency conflicts that incremental compile would miss. Most production-grade orgs leave it on; the extra minutes per deploy are worth the early failure on dependency drift.
Disable Parallel Apex Testing
Apex tests run in parallel by default, with up to five test classes executing simultaneously. Parallel execution can produce flaky failures when shared data (a singleton account record, a queueable that updates a counter) is touched by multiple tests at once. The toggle forces serial execution. It slows the test suite but eliminates a category of false-positive failures.
Sensitive Data Detection
The platform scans Apex debug logs for credit card numbers, social security numbers, and similar patterns and masks them in the log output. The setting is on by default in most modern orgs and is the cheapest insurance against accidentally leaking customer data into a developer log. Turning it off requires deliberate justification and tends to flag in Security Reviews.
Use HTTP Cookie for Visualforce View State
Visualforce view state can live in a hidden form field or in an HTTP cookie. The cookie option reduces page payload size but adds storage to every cookie. Orgs that rely heavily on Visualforce sometimes switch to cookies; orgs that are migrating off Visualforce rarely bother. The setting has no effect on Lightning Web Components.
Maximum size for Apex callout response
Apex HTTP callouts cap at 6 MB response by default. The setting lets administrators raise that ceiling to as high as 12 MB for orgs that integrate with chatty external systems. Raising the cap costs heap, so it should be the last lever pulled after API consumers are right-sized.
Long Running Tests
Some test methods legitimately take more than the standard timeout. Enabling Long Running Tests lets specific test classes opt into an extended runtime. The setting is paired with a test class annotation that flags individual methods. Most orgs need it only if they have integration-style tests that exercise async paths end to end.
Enable improved caching of org schema
The schema cache is the platform's representation of the org's metadata. Improved caching reduces the time the Apex compiler spends loading schema for every compile and test run. On large orgs with thousands of objects, the speed-up is significant. The toggle is on by default in new orgs but may not be in legacy orgs that predate the feature.
Why these settings show up in deployments
Apex Settings is captured as ApexSettings metadata. Change sets and Salesforce DX both carry the type. Deploying it from a sandbox to production applies the entire settings record. This is why two orgs that started the same way can drift apart silently over years; one admin changes a toggle, the change moves through a sandbox refresh, and both sides end up with different defaults until someone notices.
How to review and adjust Apex Settings
Apex Settings is the kind of page admins visit once and forget. A deliberate review every year or two is the right rhythm; outside of that, change one toggle at a time and validate.
- Open Apex Settings
Setup, Custom Code, Apex Settings. The page shows all available toggles with their current values.
- Document the current state
Snapshot the current values into release notes or a change log before changing anything. The page is hard to diff against history otherwise.
- Change one setting at a time
Flip one toggle, run the test suite, deploy to a sandbox, validate behaviour. Bulk changes hide which toggle caused which side effect.
- Verify in metadata
Retrieve the ApexSettings metadata via the Metadata API to confirm the change persisted as expected. Some toggles are mirrored in other Setup pages and can desync.
- Promote through environments deliberately
Move the change through dev to UAT to production using change sets or Salesforce DX. Skipping intermediate environments invites silent drift.
- Apex Settings is captured in metadata. A sandbox refresh that includes Apex Settings can quietly overwrite production toggles.
- Disabling parallel testing affects every developer, not just the test causing flakiness. Investigate the root cause before flipping a global toggle.
- Raising the callout response size cap costs heap. Right-size the integration first; raise the cap only after the simpler fixes fail.
- Some toggles surface in multiple Setup pages and metadata types. Always validate via Metadata API retrieve after a UI change.
Trust & references
Cross-checked against the following references.
- Apex SettingsSalesforce Help
- ApexSettings Metadata ReferenceSalesforce Developer Docs
Straight from the source - Salesforce's reference material on Apex Settings.
- Apex Developer GuideSalesforce Developer Docs
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…