Other Service Differences
Sandbox behavior is similar to a Salesforce production org, but important differences affect how you configure and test a sandbox org.
Required Editions
| Available in: both Salesforce Classic and Lightning Experience |
| Available in: Professional, Enterprise, Performance, Unlimited, and Database.com Editions |
| User Permissions Needed | |
|---|---|
| To view a sandbox: | View Setup and Configuration |
| To create, refresh, activate, and delete a sandbox: | Manage Dev Sandboxes (Developer or Developer Pro only) or Manage Sandboxes (all sandbox types) |
- Login history isn't copied over from the production org during creation or the source sandbox during cloning. The new sandbox is treated as a separate org with its own login history.
- Salesforce has a background process that permanently deletes records in the Recycle Bin
that are older than 15 days. This process runs at different times on different servers, so
the timestamp in your sandbox differs from the timestamp in your production org.
Applications and integrations that depend on this timestamp can fail if they’re first
connected to one environment, such as your production org, and then connected to another
environment, such as your sandbox. Consider this behavior when developing applications and
integrations that depend on this timestamp.
The time of the latest execution of the background delete process is available through the
getDeleted()API call. - For Salesforce authentication providers set up in the Summer ’14 release and earlier, the user identity provided by a sandbox doesn’t include the org ID. The destination org can’t differentiate between users with the same user ID from two sources (such as two sandboxes). To differentiate users, edit the Salesforce Auth. Provider settings in the destination org, and select the checkbox to include the org ID for third-party account links. After you enable this feature, your users must reapprove the linkage to their third-party links. Salesforce authentication providers created in the Winter ’15 release and later have this setting enabled by default.
- Only custom links created as relative URLs, such as /00Oz0000000EVpU&pv0={!Account_ID}, work when copied to your sandboxes. Custom links created as absolute URLs, such as https://MyDomainName.my.salesforce.com/00Oz0000000EVpU&pv0={!Account_ID} and https://yourInstance.salesforce.com/00Oz0000000EVpU&pv0={!Account_ID}, don’t work in your org’s sandboxes. We recommend that you use only relative URLs in your production org. Otherwise, correct the URLs in each sandbox.
- After an org’s sandbox refresh is completed, a user has login access for 10 years after
the refresh date if they are:
- A Salesforce admin.
- Copied into the sandbox from the production org, not created directly in the sandbox.
- To log in as any user, access your sandbox via the My Domain login URL for the sandbox, which you can find on the My Domain page in Setup. Alternatively, if your admin allows it, you can log in via test.salesforce.com. The option to log in as any user isn’t available when users access a sandbox from production by using the Login link.
Did this article solve your issue?
Let us know so we can improve!
