Deploying sandbox changes to production

Deploying sandbox changes to production

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. 
Examples:
  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 

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

Once you have selected the deployment type and items , the Start Deployment page will open, allowing you to check for any dependencies. You can see which items are qualified and which have conflicts.
  1. If your changes are Qualified, there will not be any issues when the changes are deployed in the production setup.
  1. 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
  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 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, 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: 

  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. Translations
  16. Wizards
  17. Tags
  18. 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 Deployment Logs 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.

Availability:
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.
  
The deployment logs will display the following details in chronological order. 

  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

You can filter through the logs using sandbox name or filter parameters like time, component and item, module, action, and user.



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 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
SEE ALSO

    • Related Articles

    • Sandbox Overview

      As your organization grows so does the complexity in your sales processes. At such a juncture, any small error in a process could have a domino effect. No organization can afford such a situation. To help overcome this hassle, Zoho CRM offers ...

    • Creating Sandbox

      Creating  sandbox account CRM admins can create multiple sandboxes in one account to test different configurations independently. While creating a sandbox you need to do the following: 1. Choose the sandbox type: There are two types of sandboxes to ...

    • Working with Sandbox

      Rebuilding a sandbox Note: Rebuild was earlier referred to as refresh When your Sandbox setup is not in sync with the Production setup, any testing that you conduct in Sandbox will not be relevant when deployed to production. So it is important that ...

    • Using multi-org feature I am unable to create a sandbox account, why is that?

      The possible reasons for not been able to create Sandbox account could be: You may not have create permission in the production CRM org. You are already part of 10 sandbox orgs. You are already super admin in 5 sandbox orgs.

    • Will Canvas Builder be available in Sandbox to design and test before pushing to production?

      This is a part of our roadmap and we will make this available soon.