SSO (Single Sign-On) SAML Settings Behavior During Sandbox Refresh — What Is Copied and What Changes

When a Salesforce sandbox is refreshed from a production environment, the Single Sign-On (SSO) configuration using SAML (Security Assertion Markup Language) is partially carried over to the refreshed sandbox — but not fully. Specifically, SAML settings are automatically disabled in the sandbox after a refresh because the Recipient URL is updated to match the new sandbox URL assigned by Salesforce.

If your production org uses SSO, users will not be able to log into the refreshed sandbox via SSO immediately after the refresh. The SAML settings must be reconfigured before SSO access is restored in the sandbox.
This article explains what SSO settings are copied during a sandbox refresh, what changes automatically, and what steps are required to re-enable SSO access in the refreshed sandbox.

What Happens to SSO Settings During a Sandbox Refresh

When a sandbox is refreshed, the following behavior applies to SSO (SAML) settings:

What is copied: All SSO configuration options from production are mirrored into the sandbox, including certificates, Identity Provider (IDP) settings, and other SAML configuration fields.
What changes: The Recipient URL is automatically updated by Salesforce to match the new sandbox URL (for example, `<REDACTED>). Because the Recipient URL changes, the SAML settings are disabled in the sandbox after the refresh.
Org ID: The sandbox org ID changes with every refresh. Because the org ID is part of the SSO configuration, this change invalidates the SSO settings and requires reconfiguration.

Important Considerations After a Sandbox Refresh

If SSO is enabled in production with a custom profile that has the SSO permission enabled, login to the sandbox may be blocked immediately after the refresh for those users. Users with standard profiles are not affected by this limitation.
After the Recipient URL is updated in the sandbox, you must download the sandbox SAML metadata and provide it to your Identity Provider (IDP). The IDP must update its configuration to reflect the new sandbox URL and org ID.
After the sandbox refresh, a system administrator may need to contact Salesforce Support to request a password reset email, which allows them to bypass the security question prompt and set up a new password to access the sandbox directly (without SSO).

Step 1: Re-Enable SAML in the Refreshed Sandbox

Log into the sandbox org as a system administrator (using username/password, not SSO).
Navigate to Setup.
In Lightning Experience: Setup | Identity | Single Sign-On Settings. In Salesforce Classic: Setup | Administer | Security Controls | Single Sign-On Settings.
Click Edit, then check the SAML Enabled checkbox.
Click Save.
Update the Recipient URL to match the sandbox URL and reconfigure any additional IDP settings as needed.

Step 2 (Alternative): Reset User Password from Production

If the sandbox administrator cannot log in due to SSO being disabled, an admin in the production org can reset the sandbox user's password:

In the production org, navigate to Setup | Users | Users list.
Locate the administrator user and click their name.
Click the Reset Password button. Salesforce sends a password reset email that allows the user to set a new password for the sandbox.