1. 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.

1. 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 

1. 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.
2. Record type: Shows which module the changes were made in.
3. Actions: Shows whether the items were added, updated, or deleted.
4. Users: Shows who made the changes.
5. Date: Shows when the changes were made.
6. 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 setlist.

Types of deployment 

1. Complete Deployment: All the components or items listed in the change set will be deployed.
   
2. Partial Deployment: Only specific components or items that you select in the change set will be deployed.

Deploy changes to production 

1. If your changes are Qualified, there will not be any issues when the changes are deployed in the production setup.
2. If your changes are Conflicted, the changes may cause issues like overriding names, missing parent items, or exceeding the feature limit. 

1. 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. However, 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, the module vehicle.
2. 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.
3. Example 3: Sandbox has edition-wise limitations. Let's say, you can create only three layouts per module, and already three layouts created in your production account. Now if you are trying to deploy another layout for the same module, then it will show a conflict message as the feature limit is getting exceeded.
   
4. Example 4: There can be situations where a developer has configured changes in your sandbox and that leads to a conflict during deployment. With the latest enhancement, you will now have the option to resolve it directly on the deployment pop-up. 

Note on CPQ Features:

1. Before deployment, check for any mismatches with the production account for all CPQ configurations. For instance, if the price rule limits are exceeded in production, deploying new price rules from the sandbox will trigger an error. Ensure that CPQ settings, product configurators, price rules, and guided selling configurations are correctly managed during deployment.
   

To deploy Sandbox changes to production

1. Go to Setup > Data Administration > Sandbox.
   
2. Click on the sandbox you want to deploy.
   
3. In the Change Set list, select the changes you want to deploy.
1. If you want to deploy all changes to production, select the checkbox at the left of the Components and item header and click Deploy Changes to Production button.
   
2. If you want to deploy the changes partially, select the checkbox of the specific components and click the Deploy Changes to Production button.
   
4. View the details of all the qualified and conflicted changes on the Start Deployment page, resolve any conflicts, and click the Yes, Proceed button.
   
   

Points to remember:

1. You can deploy the following configurations for production from the sandbox account: 

1. Profiles
2. Roles
3. Data Sharing Settings
4. Groups
5. Multi-currency
6. Territory Management
7. Automation
8. Customization
9. Templates
10. Custom Schedules
11. Webforms
12. Auto Response Rules
13. Workflow Rules
14. Blueprint 
    
15. Approval processes
    
16. Review processes
    
17. Journey Builder
    
18. Translations
    
19. Wizards
    
20. Tags
    
21. Map Dependency Fields
    
22. Canvas
    
23. Zoho Survey
    
24. Zoho Social
    
25. CPQ Features:
    
1. Product Configurator
   
2. Price Rules
   
3. Guided Selling
   
4. CPQ permissions
   
26. Services and Appointments
    
27. Google Calendar

Note: Changes made to Translations will sometimes reflect inside the 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 testing purposes. 

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 a selected number of records from the live CRM account to specific modules. 

7. Updating a field in the sandbox and deploying the changes to production will overwrite the existing field properties. For example, if the email field is marked as "mandatory" in the sandbox and as a "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 Deployment Logs tab near the 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.

Permission Required

Users with 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.

 

1. The date of the deployment

2. The name of the sandbox environment the changes were deployed from

3. The changes that were deployed
   

4. The user who deployed the changes
   

Note

1. 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 is configured in the 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 to deploy the changes.
   
   
2. You can simply choose to replace the developer from the list of available users in the org in the deploy changes window directly.
   
   

SEE ALSO

Working with Sandbox

Creating Sandbox

Make configurations in Sandbox

Creating a Blueprint in Sandbox