Schema Settings
Schema Settings is a Setup page in Salesforce that exposes a small but important set of org-wide toggles controlling how the data schema behaves.
Definition
Schema Settings is a Setup page in Salesforce that exposes a small but important set of org-wide toggles controlling how the data schema behaves. The settings here are not about a single object or field. They are global switches that decide whether the org supports external sharing models, whether users can truncate custom objects, whether deleting a master record sends its detail records to the Recycle Bin, and how field history capture is managed.
Most of these toggles are one-way doors or have meaningful consequences across thousands of records. Schema Settings sits inside Setup under Schema Settings (older orgs) or Data Classification depending on release, and the permissions required to edit it are Customize Application plus, for some toggles, Modify All Data.
The org-wide switches that shape your schema
External sharing model
The External Sharing Model toggle on Schema Settings splits your org-wide defaults into two columns: one for internal users and one for external users (Partner, Customer, Customer Community, etc.). Before this is enabled, external users inherit the same OWD as internal users, which often forces an org into Private defaults just to keep external traffic locked down. After it is enabled, you can keep the internal default at Public Read/Write for collaboration while setting the external default to Private for the same object. The catch: enabling external sharing is irreversible without Salesforce Support involvement, and every object you have records in will need its sharing rules audited. Sandboxes are the right place to validate the impact before production.
Custom object truncate
Truncate is a destructive operation that empties a custom object of all its records without going through the delete pipeline. It is faster than mass delete, but it also strips field history, drops sharing recalculations, and skips Apex triggers entirely. Schema Settings exposes the Allow Truncate Custom Objects toggle, which is off by default. Turn it on only when you have a real cleanup scenario, usually a sandbox refresh or a bad data load that needs to disappear in seconds rather than hours. The object you truncate must have zero references from other objects, no record types, no detail relationships, and no Apex code that depends on its data. The truncated records are not in the Recycle Bin. They are gone.
Cascade delete into the Recycle Bin
When you delete a master record on a master-detail relationship, every detail record gets deleted too. The Schema Settings toggle Cascade Delete of Detail Records into Recycle Bin controls whether those detail records are recoverable for 15 days or disappear immediately. Off by default, the detail records bypass the Recycle Bin and cannot be restored individually. On, both the master and the details sit in the Recycle Bin and an admin can restore them together. For finance, services billing, and any object where a deleted detail row could mean lost audit trail, flip this on early and document the reason in your change log.
Manage Field History Capture
The Manage Field History Capture toggle, when enabled, gives admins control over which fields are tracked for field history without requiring Modify All Data. With the setting off, only system administrators with that broad permission can change tracked fields. With it on, any user with Customize Application can change the tracking configuration on objects they manage. The reason this matters: many orgs separate the role of schema administrator from the role of data administrator, and Modify All Data is too broad to hand out just to let someone add Phone to the Contact field history list.
Read-only field changes via API
Salesforce blocks SOAP and REST API updates to certain system fields like CreatedDate, CreatedById, LastModifiedDate, and LastModifiedById by default. Data migration scenarios often need to preserve those values when loading historical data from a legacy system. The Allow Create Audit Fields permission on the user profile, combined with the org-wide Schema Settings enabling that permission, lets API callers set those fields on insert. The fields can still not be updated after creation. This is a one-time write at the moment of record creation, which is exactly what migrations need but nothing more.
Schema Settings versus other Setup pages
Schema Settings is sometimes confused with adjacent Setup areas. Data Classification configures sensitivity labels on fields. User Interface Settings controls list view, search layout, and quick action behavior. Schema Builder is a graphical editor for objects and fields. Schema Settings is none of those. It is the org-level container for the global behavior toggles that affect how every object behaves with respect to sharing, deletion, history, and API audit fields. If a question is about a per-object setting (page layouts, validation rules, triggers), it belongs elsewhere. If it is a switch that applies to the whole org, Schema Settings is often the right home.
When Schema Settings does not have the answer
Not every org-wide toggle lives on Schema Settings. Field-level encryption settings live under Platform Encryption. Sharing reasons and apex sharing live on the object setup pages. Person Account enablement lives under Account Settings. Critical Updates and deferred sharing maintenance live on their own pages. Schema Settings is the right home for a specific kind of switch: behaviors that affect every object's schema-level interaction with sharing, deletion, audit fields, and history. When in doubt, search the Setup Quick Find by the behavior you are trying to control (External Sharing, Truncate, Field History) rather than guessing where the toggle lives. Salesforce moves these pages between releases, and the search bar tracks the current location even when help articles lag a release behind.
Configure Schema Settings safely
Schema Settings toggles affect the entire org. Sandbox first, document the change in your release notes, and confirm with the team that no integration or report depends on the current behavior. Below is the standard sequence to follow when you need to flip one of these switches.
- Open Schema Settings in a sandbox
Log in to a Full Copy or Partial Copy sandbox that mirrors production data and metadata. From Setup, enter Schema Settings in the Quick Find box and select the page. Read each toggle's help text before changing anything. The page lists every option with a one-line description, and many options have a learn-more link to Help documentation that covers the side effects in more depth.
- Flip the switch and capture before/after state
Take a screenshot of the Schema Settings page in its current state before you change anything. Make the change, save, and screenshot again. Add both screenshots to your change request ticket. This becomes the audit trail. Sandbox toggles do not flow to production automatically through a change set, so the production move will be a separate manual step done by an authorized admin.
- Test integrations, sharing rules, and reports
After the sandbox toggle is on, run your standard regression script. For external sharing, refresh the OWD page for every object that has community or partner traffic, then re-test community user logins to confirm they see what they should and nothing more. For cascade-delete-to-recycle, manually delete a master record and confirm the detail records appear in the bin with the right retention window. For truncate, point a sandbox-only utility at the target object and verify the records are gone in seconds.
- Promote to production with change management
Schedule the production change for a maintenance window or a low-traffic period. Log in to production, navigate to Schema Settings, and flip the same switches one by one. Re-screenshot. Notify integration owners and downstream teams via email or Slack that the new behavior is live. Add the change to the org's running architecture log so future admins can answer the question "when did external sharing get turned on?" without having to dig through the setup audit trail.
- External Sharing Model is effectively irreversible. Once you split the OWD into internal and external columns, Salesforce treats the change as permanent. Reverting requires a support case and is not always granted.
- Truncate skips Apex triggers, workflow, and validation rules. Any logic that depends on the delete event will not fire. Audit your automations before enabling the truncate toggle.
- Cascade delete to Recycle Bin only applies to master-detail relationships. Lookup relationships with cascade-delete enabled at the field level follow their own rules.
- Allow Create Audit Fields is a per-user-profile permission, not a global flip. The Schema Settings page enables the capability, but each user who needs it still requires the permission on their profile or permission set.
- Schema Settings changes are tracked in Setup Audit Trail, but the audit log only goes back six months by default. For long-running governance, copy the audit row into your org's external architecture log on the day of the change.
Trust & references
Cross-checked against the following references.
- Schema SettingsSalesforce Help
- External Organization-Wide Defaults OverviewSalesforce Help
- Create Audit Fields on InsertSalesforce Help
Straight from the source - Salesforce's reference material on Schema Settings.
- Schema SettingsSalesforce Help
- Truncate Custom ObjectsSalesforce Help
- Field History TrackingSalesforce Help
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. What is a Governor Limit in the context of Schema Settings?
Q2. What is required before deploying Schema Settings-related code to production?
Q3. Where would a developer typically work with Schema Settings?
Discussion
Loading discussion…