Sandbox mimics your production environment, allowing you to test real-time business scenarios with CRM data and deploy the configurations from sandbox to production without any impact on the original data.
- Create a blueprint, simulate a process, and deploy it to the parent CRM account without making any changes to the live environment until everything is running smoothly.
- As an admin, you can change the organization's hierarchy to test the behavior of the CRM data, check whether the data sharing properties in the organization are affected, and deploy only the changes you need to the parent account.
View Changes before deployment
Once a sandbox is created, changes made in that sandbox will be listed under the
change set list within the respective sandbox environment. The changes are categorized and aggregated based on the following parameters.
- Components and items: Shows all the changes made (items) for each feature (component). For example, if a group is created in the sandbox, then Group will be the component and the name you entered for that group in the sandbox will be the item.
- Record type: Shows which module the changes were made in.
- Actions: Shows whether the items were added, updated, or deleted.
- Users: Shows who made the changes.
- Date: Shows when the changes were made.
- Linked: Shows other items associated with the selected item. For example, in the screenshot below, the link icon shows that the Pacific Contacts layout is associated with the changed item Secondary Contact.
You can also filter these changes based on the parameters by clicking on the funnel icon on the right side of the change set list.
Types of deployment
When you deploy your changes to production, you can choose either complete deployment or partial deployment as required.
- Complete Deployment: All the components or items listed in the change set will be deployed.
- Partial Deployment: Only specific components or items that you select in the change set will be deployed.
Deploy changes to production
Once you have selected the deployment type and items
Start Deployment page
will open, allowing you to check for any dependencies. You can see which items are qualified and which have conflicts.
- If your changes are Qualified, there will not be any issues when the changes are deployed in the production setup.
- If your changes are Conflicted, you cannot proceed with the deployment as the changes may cause issues like overriding names, exceeding feature limit, missing parent items.
When there are conflicting changes, those changes will not be pushed to the deployment until they are rectified.
Example 1: If you have a module named vehicle in your production account and you create a field in that module inside the Sandbox account. But due to some reasons, the vehicle module has been deleted. Now, if you deploy the changes to the production setup, a conflict occurs due to the missing parent item - in this case, module vehicle.
Example 2: In the vehicle module, there is a field named insurance. When the same name has been used to create a field in the vehicle module inside the sandbox, a conflict occurs due to the name overriding.
You can view the details about the qualified and conflicted deployments and confirm the deployment.
To deploy Sandbox changes to production
- Go to Setup > Data Administration > Sandbox.
- Click on the sandbox you want to deploy.
- In the Change Set list, select the changes you want to deploy.
- If you want to deploy all changes to production, select the checkbox at the left of Components and item header and click Deploy Changes to Production button.
- If you want to deploy the changes partially, select the checkbox of the specific components and click the Deploy Changes to Production button.
- View the details of all the qualified and conflicted changes on the Start Deployment page, rectify any conflicts, and click the Yes, Proceed button.
Points to remember:
1. You can deploy the following configurations for production from the sandbox account:
- Data Sharing Settings
- Territory Management
- Custom Schedules
- Auto Response Rules
- Workflow Rules
- Map Dependency Fields
Note: Changes made to Translations will sometimes reflect inside production account in a delayed manner depending on the file size.
2. However, Sandbox currently does not support Scoring Rules.
3. Sandbox allows you to test what happens not only when you add new configurations, but also when you edit or delete an existing configuration.
4. Emails sent from the Sandbox environment will not be delivered to the recipients, it is only for the testing purpose.
5. Emails triggered through Workflow Rules or Blueprints will not be delivered to the recipients, however, these emails will be displayed in the Email related list of the record.
6. Data cannot be migrated to Sandbox from other CRM sources You can however, import records or populate sample data or selected number of records from the live CRM account to specific modules.
7. Updating a field in sandbox and deploying the changes to production will overwrite the existing field properties. For example, if the email field is marked as "mandatory" in sandbox and as "unique field" in production. Then, after deployment the field property will be overwritten to mandatory.
8. To know whether you are working on the Sandbox environment or production setup, look out for a bright orange Sandbox ribbon. This is used to differentiate Sandbox from your production setup.
9. Sandbox is used to test and validate configurations before they are moved onto the production account, therefore, records populated, imported or manually added to the Sandbox account cannot be deployed to production.
10. The changes deployed via Sandbox in the last 6 months will be listed in the
tab near Sandbox list.
Track the deployed changes
Once you have deployed the changes to the live account, the details about the deployment will be listed in the deployment logs tab.
Manage Sandbox Permission can view and filter the logs of all sandbox environments.
Other users who are associated to a particular sandbox environment, can only view and filter the logs of that particular sandbox.
The deployment logs will display the following details in chronological order.
The date of the deployment
The name of the sandbox environment the changes were deployed from
The changes that were deployed
The user who deployed the changes
You can filter through the logs using sandbox name or filter parameters like
time, component and item, module, action, and
- In Sandbox, if any configuration is assigned or associated with a Developer, then the changes can't be deployed to the production account.
Say an assignment rule configured is in Sandbox such that the records that match the criteria will be assigned to the Developer. In that case, a conflict will be displayed while deploying the changes to the production account. The user should be changed in order to deploy the changes