Review some important considerations about access before you create a sandbox so that
sandbox users can make full use of the sandbox environment for development and UAT
testing.
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) |
- Access changes to consider for sandbox users:
- A sandbox refresh deletes and recreates the sandbox as a copy of the production org.
This process reverses any manual access changes you made. If you created sandbox-only
users, then they no longer exist. Other users’ profile and permissions revert to their
values in the production org. After a refresh, make any access changes in the new
copy.
- You can create users in your production org that are inactive, and then activate them
in a sandbox. This method is a good way to create a user that has the appropriate
permissions to develop in a sandbox.
- Many development and testing tasks require the Modify All Data permission. If your
developers don’t have that permission in the production org, increase their permissions
in the sandbox. Exercise caution when granting this permission in a sandbox that
contains sensitive information copied from production (for example, social security
numbers).
- Users added in a production org after creating or refreshing a sandbox don’t have
access to the production org instance’s related sandboxes. To create users in a sandbox,
log in as the administrator on the sandbox org and create them in the sandbox instance.
- You can create users for sandbox development, but these new users count against the
number of licensed users in your org. To reduce your license count, you can disable
production users who don’t need access to the sandbox before you create or refresh a
sandbox.
- Always log in to your sandbox org using either the My Domain login URL for the sandbox or
https://test.salesforce.com. My Domain login URLs are recommended
because they add an extra layer of security. Sandbox My Domain login URLs are in the format
MyDomainName--SandboxName.sandbox.my.salesforce.com.
You can find an org’s My Domain login URL on the My Domain Setup page.
- Admins can log in to a sandbox via the Log In action on the
Sandboxes Setup page only when the My Domain option Prevent login from
https://test.salesforce.com is disabled in the sandbox. If that option is
enabled, log in via the sandbox’s My Domain login URL instead.
- Remember to log in using the modified username as described in Users and Contacts.
- If using the API, after you log in, use the redirect URL that is returned in the
loginResult object for subsequent access. This URL reflects the instance on which the
sandbox is located and the appropriate server pool for API access.
- Sandbox copies are made with federated authentication with SAML
disabled. Configuration information is preserved, except the value for Salesforce Login
URL. Salesforce Login URL is updated to match your sandbox URL, for example
https://yourInstance.salesforce.com/, after
you re-enable SAML. To enable SAML in the sandbox, from Setup, in the Quick Find box,
enter Single Sign-On Settings, and then select Single
Sign-On Settings. Then click Edit, and
select SAML Enabled. For more information about configuring
SAML settings, see Configure SAML Settings for Single Sign-On.
Note After a sandbox is created or refreshed, it can take 24–48 hours before you’re able to log in using https://test.salesforce.com. During this period, access your sandbox via its My Domain login URL.