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.