how to create new sandbox - Answers - Salesforce Trailblazer Community
Trailblazer Community
Ask Search:
Bikram Raj DuttaBikram Raj Dutta 

how to create new sandbox

i want to have access as a  admin user which requires to create a sandbox and under data management option i don't i have an option for sandbox.Is there any another way to create a sandbox.
Sunil KeshariSunil Keshari
To create a sandbox, you should be have “View Setup and Configuration” and “Modify All Data”
 permissions.

To create sandboxes follow these directions:

1. Login to Salesforce.com
2. Click on Setup | Administration Setup | Data Management | Sandbox
3. Click the button “New Sandbox”
4. Give the sandbox a name, a description, and the type.
5. Click the button “Start Copy”.

If you do not see “Sandbox” under Data Management then your company may not have purchased any sandboxes and you will need to contact your sales representative.


Sunil KeshariSunil Keshari
More details on sandbox creations -

https://help.salesforce.com/HTViewHelpDoc?id=data_sandbox_implementation_tips.htm&language=en_US

Sandbox Setup Tips and Considerations

Available in: Enterprise, Unlimited, and Database.com Editions

User Permissions Needed
To view a sandbox: “View Setup and Configuration”
To create, refresh, activate, and delete sandboxes: “Modify All Data”

Consider the following before you create a sandbox.

Servers and IDs

  • The organization IDs of your sandboxes differ from your production organization ID, and will change each time your sandbox is refreshed.
  • Salesforce stores sandbox organizations on several instances. When a sandbox is created or refreshed, an instance is selected for your sandbox, so your sandbox may appear on different instances and have different URLs.
  • When data that contains object IDs is copied from your production instance into your sandbox, the object IDs in your sandbox match the object IDs in your production instance. However, data created in your production instance or sandbox will not contain matching object IDs.

Username and Email Address Modification

  • User information is included in a sandbox copy or refresh for all sandbox types. Because all Salesforce usernames must be unique and reference a single organization, all copied usernames are modified to ensure uniqueness during the copy process. Usernames are modified differently for each sandbox copy. Entering a particular modified username will log you into a specific sandbox.
  • For each username, the copy process applies one or two modifications as necessary to generate a unique new username:
    • First, the sandbox name is appended to the username, so that for a sandbox named test, user@acme.com may become user@acme.com.test.
    • If the resulting username is not unique, a second modification is performed in which a number of characters and digits are prepended to the modified username. This second modification may result in a username such as 00x7Vquser@acme.com.test.
  • Email addresses are modified in a sandbox so that production users, who may not know of the sandbox, don’t receive automatically generated email messages from the sandbox, such as notifications from triggered workflow or escalation rules. By modifying user email addresses, any email messages sent from the sandbox aren’t delivered to production users.
  • You can manually correct email addresses in the sandbox user records for users who will use the sandbox for testing and training.
    Warning
    Sandboxes automatically change Salesforce user email addresses, but don’t change other email addresses in Salesforce, such as those in contact records. To avoid sending unsolicited email from your sandboxes, manually invalidate or delete all email addresses in your sandboxes that don’t belong to users. When testing the generation of outbound email, change contact email addresses to those of testers or an automated test script.

Creating, Refreshing, and Deleting Sandboxes

  • Sandbox copy is a long-running operation that occurs in the background. You are notified of the completion of a sandbox copy via email. Sandbox refreshes may complete in minutes, days, or even more than a week.
  • A number of conditions factor into the duration of a sandbox copy or refresh, including the number of customizations, data size, numbers of objects and configuration choices (for full copies), and server load. Also, sandbox refreshes are queued, so your requested copy may not start immediately after your request.
  • A sandbox is not a point-in-time snapshot of the exact state of your data. Furthermore, we recommend that you limit changes to your production organization while a sandbox is being created or refreshed. Setup and data changes to your production organization during the sandbox creation and refresh operations may result in inconsistencies in your sandbox. You may detect and correct some inconsistencies in your sandbox after it is copied or refreshed.
  • Some types of sandboxes may not be available to choose from if you already reached your organization's limit of the types of sandboxes you can create or refresh. For example, if your organization is limited to one full sandbox, and a full sandbox is already created, you may not select Full when creating a new sandbox. However, you may refresh your existing full sandbox.
  • When you are finished with a sandbox, you can refresh it to create a new copy. However, if you have reduced your organization's number of sandboxes, a Delete link displays next to existing sandboxes, allowing you to delete a sandbox of your choice. Note that you must delete a sandbox before you can refresh any more sandboxes.
  • If you have active Salesforce-to-Salesforce connections in your sandbox, you must deactivate and then reactivate the connection(s) after the sandbox is refreshed.

Configuring Full Sandboxes

When you create or refresh a full sandbox, you can configure it not to copy some data that is generally not useful in a sandbox. Keeping the minimum selections will speed up your sandbox copy.

  • The Object History and Case History options allow you to select the number of days of history from your production organization to copy to your sandbox. You can copy from 0 to 180 days, in 30 day increments. The default value is 30 days.
  • By default, Chatter data won’t be copied to your sandbox. Chatter data includes feeds, messages, and discovery topics. Select the Copy Chatter Data checkbox if you need to copy it.
  • The setup audit trail history of your production organization won’t be copied to your sandbox. The audit trail for your sandbox organization will start when you begin to use it.
  • Archived activities (tasks and events that aren’t available in the production organization because they’re over a year old) and password history (users’ previous passwords) won’t be copied to your sandbox.
Note
Don’t increase the default selections unless special circumstances require it. Too much data can cause significant delays in the time it takes to copy your sandbox.

Accessing Sandboxes

  • Access changes for sandbox users:
    • A sandbox refresh deletes and recreates the sandbox as a new copy of the production organization. In effect, this reverses any manual access changes you've performed. If you created sandbox-only users, they will no longer exist, and a user’s profile and permissions revert to their values in the production organization. This means that after a refresh, any access changes will need to be repeated in the new copy.
    • You can create users in your production organization that are inactive, and then activate them in a sandbox. This is a good way to create a user in a sandbox that has the appropriate permissions to develop in a sandbox. For more information, see Editing Users.
    • Many development and testing tasks require the “Modify All Data” permission. Because your developers might not have that permission in the production organization, you may need to increase their permissions in a sandbox. Exercise caution when granting this permission in sandbox organizations that contain sensitive information copied from production (for example, social security numbers). For more information on permissions, see Overview of User Permissions and Access.
    • You can create new users for sandbox development, but these count against the number of licensed users in your organization. To reduce your license count, you can disable production users who won’t need access to the sandbox. For more information, see Deactivating Users.
    • To grant users access to a sandbox, you must log in as the administrator on the sandbox organization, and then create or upgrade user access in the sandbox.
  • Always log in to your sandbox organization using the https://test.salesforce.com login URL.
  • Remember to log in using the modified username as described in Username and Email Address Modification.
  • If using the API, after you log in you must 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.
  • All sandbox copies are made with federated authentication with SAML disabled. Any configuration information is preserved, except the value for Recipient URL changes to http://tapp0.salesforce.com. The Recipient URL is updated to match your sandbox URL, for example http://cs1.salesforce.com, after you re-enable SAML. To enable SAML in the sandbox copy, click Your Name | Setup | Security Controls | Single Sign-On Settings; then click Edit, and select SAML Enabled. You must change the value of the Recipient URL in the certificate for your client application as well. For more information, see Configuring SAML Settings for Single Sign-On.

Sandbox Storage Limits

  • Full copy sandboxes have the same storage limit as your production organization.
  • Configuration-only sandboxes have a 500 MB storage limit.
  • Developer sandboxes have a 10 MB storage limit.
  • Sandboxes don’t send email notifications when storage limits are reached. However, if you reach the storage limit of your sandbox, you cannot save new data in your sandbox. To check your storage limits, click Your Name | Setup | Data Management | Storage Usage in your sandbox. For more information on storage limits, see Monitoring Resources.

Customization and Data Changes

  • Customizations and data changes in your production organization don’t automatically appear in your sandboxes. You must create a new sandbox or refresh an existing one to see the customizations made to your organization since the last time you created or refreshed a sandbox.
  • You can only add, edit, or delete Apex using the Salesforce user interface in a Developer Edition or sandbox organization. In a Salesforce production organization, you can only make changes to Apex by using the compileAndTestAPI() call. For more information, see the Force.com Apex Code Developer's Guide.
  • If your sandbox is the same version as Force.com AppExchange, you can:
    • Install and deploy apps from Force.com AppExchange in your sandbox.
    • Publish apps from your sandbox to Force.com AppExchange.

      Publishing managed packages from a Force.com Sandbox is not advised, as refreshing or deleting the sandbox will prevent any revisions to that managed package.

    The version of your sandboxes may differ from Force.com AppExchange around the time of a Salesforce release. Check the logo in the upper left corner of your sandbox home page for version information.

  • If your organization uses quote templates, and you create a configuration-only sandbox, templates that contain Text/Image fields cannot be opened for editing within the sandbox.

Service Exclusions

  • The following features are disabled and cannot be enabled in sandboxes:
    • Case escalation
    • Opportunity reminders
    • Contract expiration warnings
    • Subscription summary
    • Data exports (using Export Now or Schedule Export on Your Name | Setup | Data Management | Data Export)
    • The ability to create Salesforce sandboxes.

      Case escalation, opportunity reminders, and contract expiration warnings are disabled because they automatically send email to contacts, customers and users who should not interact with sandboxes.

    • Testing Salesforce for Google AdWords in your sandbox is not supported. Attempting to test Salesforce for Google AdWords in your sandbox will result in errors because your sandbox organization operates with the same link to your Google AdWords account as your production organization.
    • Email service addresses that you create in your sandbox cannot be copied to your production organization.

Other Service Differences

  • Only custom links created as relative URLs, such as /00Oz0000000EVpU&pv0={!Account_ID} will work when copied to your sandboxes. Custom links created as absolute URLs, such as https://na1.salesforce.com/00Oz0000000EVpU&pv0={!Account_ID}, don’t work in your organization's sandboxes. We recommend that you use only relative URLs in your production organization. Otherwise, you will need to correct the URLs in each sandbox.
  • Salesforce has a background process that permanently deletes records in the Recycle Bin that are older than 30 days. This process runs at different times on different servers, so its timestamp in your sandbox differs from its timestamp in your production organization. Applications and integrations that depend on this timestamp may fail if they are first connected to one environment, such as your production organization, and then later connected to another environment, such as your sandbox. Keep this in mind when developing applications and integrations that depend on this timestamp.

    Note that the time of the latest execution of the background delete process is available through the getDeleted() API call. For more information, see the SOAP API Developer's Guide.

david chengdavid cheng
Also - sandbox is only available in Enterprise and Unlimited Editions.