---
schema_version: "1"
id: 7735d83e9d2841d712607b6079852194e7858533e0b28eddd6accc8fad1bac25
title: Other Service Differences
collection: admin
version: current
locale: en-us
portal_url: https://docs.salesforce.com/admin/current/en-us/platform/264-0-0/data_sandbox_other_service_differences.md
canonical_url: https://help.salesforce.com/s/articleView?id=platform.data_sandbox_other_service_differences.htm&release=264.0.0&type=5
source_site: help.salesforce.com
content_type: documentation
content_hash: 619dbd4b74905c4c573db46d7def0d65cadde175841656d4f5acaa418ded0a7f
description: Sandbox behavior is similar to a Salesforce production org, but important differences affect how you configure and test a sandbox org.
products:
  - Salesforce Platform
release: "264"
---
# 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

<table class="slds-table slds-table_bordered slds-max-medium-table_stacked slds-m-bottom_small edition"><colgroup><col></colgroup><tbody><tr class=""><td class="slds-cell-wrap" style="vertical-align:top;">Available in: both Salesforce Classic and Lightning Experience</td></tr><tr class=""><td class="slds-cell-wrap" style="vertical-align:top;">Available in: <strong>Professional</strong>, <strong>Enterprise</strong>, <strong>Performance</strong>, <strong>Unlimited</strong>, and <strong>Database.com</strong> Editions</td></tr></tbody></table>

<table class="slds-table slds-table_bordered slds-max-medium-table_stacked slds-m-bottom_small permission">
      <colgroup>
        <col style="width:50%">
        <col style="width:50%">
      </colgroup>
      <thead class="slds-text-title_caps ">
        <tr class="">
          <th scope="colgroup" class="slds-cell-wrap" colspan="2" style="text-align:center;vertical-align:top;" id="d16112e73">User Permissions
            Needed</th>
        </tr>
      </thead>
      <tbody>
        <tr class="">
          <td data-label="User Permissions Needed" class="slds-cell-wrap" style="vertical-align:top;" headers="d16112e73 ">To view a sandbox:</td>

          <td class="slds-cell-wrap" style="vertical-align:top;" headers="d16112e73 ">View Setup and Configuration</td>

        </tr>
        <tr class="">
          <td data-label="User Permissions Needed" class="slds-cell-wrap" style="vertical-align:top;" headers="d16112e73 ">To create, refresh, activate, and delete a sandbox:</td>

          <td class="slds-cell-wrap" style="vertical-align:top;" headers="d16112e73 ">Manage Dev Sandboxes (Developer or Developer Pro only) or Manage Sandboxes (all
            sandbox types)</td>

        </tr>
      </tbody>
    </table>

- 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](https://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.