How to Resolve: Salesforce “Personal Settings” resetting to System Default

When users log into Salesforce and find their individual user preferences—such as Time Zone, Locale, Language, Default Currency, or Navigation Bar items—reset back to company defaults, the issue is rarely a random platform glitch. This behavior is almost always driven by an automated synchronization process: an Identity Provider (IdP) executing Just-In-Time (JIT) provisioning, automated SCIM directory synchronizations, or internal Record-Triggered Flows and scheduled scripts that overwrite fields on the User object during authentication.

Fast Fix

Audit your Single Sign-On (SSO) SAML or OIDC attribute mappings in your Identity Provider (Okta, Azure AD/Entra ID, Ping). If your IdP sends blank or default attributes for TimeZoneSidKey, LocaleSidKey, or LanguageLocaleKey during login assertions, Salesforce overwrites the user’s manual settings on every single login. Set your IdP to omit these attributes on updates or map them to the user’s actual corporate profile settings.

---

Diagnostic Snapshot

• Symptom: User-defined preferences (Time Zone, Locale, Language, Display Density, App Navigation) revert to system defaults after logging in or overnight.
• Underlying Architecture: Single Sign-On (SAML 2.0 / OIDC JIT Provisioning), SCIM User Provisioning APIs, User Object Automation.
• Common Perpetrators: Identity Provider assertion overwrites (Azure AD / Okta), automated nightly user-sync scripts, or unmanaged browser profile wiping.
• Permissions Needed: System Administrator access to review Single Sign-On Settings, Login History, and the User Object audit trail.

---

Why Personal Settings Get Overwritten

Salesforce stores individual user preferences directly on the User standard object. Fields include:

• TimeZoneSidKey (e.g., America/New_York)
• LocaleSidKey (e.g., en_US)
• LanguageLocaleKey (e.g., en_US)
• DefaultCurrencyIsoCode (for multi-currency orgs)

Because these settings are database fields on the User record, any process that updates the user record can overwrite them.

When an organization enforces Single Sign-On (SSO):

1. The user logs in via an Identity Provider (like Microsoft Entra ID).
2. The IdP sends a SAML assertion or OIDC token containing claims about the user.
3. If Just-In-Time (JIT) Provisioning or SCIM user provisioning is active, Salesforce updates the User record with the values supplied in the assertion.
4. If the IdP does not have a user’s specific time zone configured, it may transmit a null value or the corporate default time zone. Salesforce updates the field, wiping out the user’s previous manual customization.

---

Diagnostic Path

User Reports Personal Settings Reverting
 ├── Check Setup ──► View Setup Audit Trail
 │    ├── Filter for edits to the affected User record
 │    ├── Who made the change?
 │    │    ├── "Automated Process" / Integration User ──► Check Scheduled Flow / Apex
 │    │    └── The User Themselves (at login timestamp) ─► Check SSO / SAML JIT Mapping
 └── Does the issue affect UI Display Settings only (Tabs, Density)?
      └── Check Browser Cache / Shared Virtual Desktops (VDI)

Step 1: Inspect the Setup Audit Trail

1. In Setup, enter View Setup Audit Trail in the Quick Find box.
2. Download the past 30 days of audit logs as a CSV file.
3. Search for the affected user’s name or User ID.
4. Look for entries modifying user properties:
   • Example: Changed Time Zone for user Jane Doe from (GMT-05:00) Eastern Standard Time to (GMT+00:00) Greenwich Mean Time.
5. Note the User column. If the user who made the change is listed as the user themselves—and the timestamp matches their exact login time—the update was triggered by an SSO login assertion.

---

Step-by-Step Resolution

1. Correct Identity Provider (IdP) SAML/OIDC Attribute Mappings

If using SSO with SAML JIT or SCIM provisioning (Okta, Entra ID, PingFederate):

1. Open your enterprise Identity Provider administration console.
2. Locate the Salesforce Enterprise Application integration.
3. Open the Attribute Mappings or SAML Claims configuration:
   • Look for mappings targeting User.TimeZoneSidKey, User.LocaleSidKey, and User.LanguageLocaleKey.
4. The Fix:
   • If your IdP does not actively manage accurate user time zones, delete the attribute mapping entirely. Do not send the claim in the SAML assertion.
   • If using Okta or Entra ID SCIM, change the update rule for those attributes from “Always Apply” to “Only apply during record creation”. This allows the initial user provisioning to set a baseline default without overwriting subsequent manual edits made by the user in Salesforce. If your SSO setup is experiencing broader handshake errors, reference How to Resolve: Salesforce “Connected App” failing OIDC Handshakes.

2. Audit Custom JIT Handler Apex Classes

If your organization uses a custom Apex class to process SAML assertions:

1. Go to Setup > Single Sign-On Settings.
2. Click on your active SAML configuration.
3. Look at the Just-in-Time Provisioning section.
4. If Custom JIT Handler is enabled, open the referenced Apex class (e.g., CustomJitHandler).
5. Inspect the updateUser() method:

// The Problematic Code: Hardcoded default overwriting user edits on every login
global void updateUser(Id userId, Id samlSsoProviderId, Id communityId, Id portalId,
                       String federationId, Map<String, String> attributes, String assertion) {
    User u = [SELECT Id FROM User WHERE Id = :userId];

    // Antipattern: Resets setting unconditionally on every login
    u.TimeZoneSidKey = 'America/Los_Angeles';
    update u;
}

• The Fix: Remove hardcoded field assignments from the update sequence, or add logic that checks if the field already contains a value before assigning a fallback:

// Corrected: Only assign default if the user currently lacks a setting
if (String.isBlank(u.TimeZoneSidKey) && attributes.containsKey('TimeZone')) {
    u.TimeZoneSidKey = attributes.get('TimeZone');
    update u;
}

3. Audit Automated Background Record-Triggered Flows

Check for internal automations targeting the User object:

1. In Setup, go to Process Automation > Flows.
2. Filter by the User object.
3. Review any Record-Triggered Flows that run on User updates or creations.
4. Verify that background processes updating user license assignments or division settings do not accidentally assign company-wide defaults to locale fields. To ensure your flows do not trigger cascading data issues, see How to Resolve: Salesforce “Flow” stuck in an Infinite Recursive Loop.

4. Address Non-Persistent Virtual Desktops (VDI)

If the user settings being lost are Display Density (Comfy vs. Compact) or custom Navigation Bar Tab Ordering:

• These specific layout preferences are stored in the user’s local browser storage (localStorage and IndexedDB), not on the User record in the database.
• In environments using non-persistent virtual desktops (such as Citrix or VMware Horizon) that wipe user profiles upon logout, these client-side settings are deleted daily.
• Work with your IT infrastructure team to ensure that virtual desktop user profile disks (such as FSLogix) include persistent synchronization for the browser’s local application data folder.

---

Common Misdiagnoses

• Default Company Information Changes: If all users across an entire subsidiary suddenly report changed time zones or currencies simultaneously, check Setup > Company Information. An administrator may have updated the company-wide default time zone or currency, which shifts display parameters for users whose profiles did not have an explicit override set.
• Corrupted Sandbox Metadata Overwrites: If this issue occurs following a sandbox refresh, the process mirrors production user records and resets local testing user profiles. For troubleshooting post-refresh irregularities, see Fix: Salesforce “URL No Longer Exists” after Sandbox Refresh.

---

Hard Stops

• Do not apply a mass data-load to reset User records without first halting active IdP provisioning jobs. If you run a Data Loader script to restore user time zones while the Identity Provider is still pushing bad claims, the IdP will overwrite your corrections the very next time each user logs in. Disable or correct the IdP attribute mapping before repairing user records.