Sandbox Access Considerations
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.
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. - 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.
Did this article solve your issue?
Let us know so we can improve!
