All Collections
Help Articles
Data Deploy Best Practices
Data Deploy Best Practices
Scott Sherwood avatar
Written by Scott Sherwood
Updated over a week ago

Overview

We’ve listed some of the best practices you can implement in your Salesforce organization to get the best value addition from Copado.

Copado Data Deploy

  • Leverage the Schema Builder feature by Salesforce before you start working with data templates.

    • The Schema Builder provides a detailed view of your data model and lets you have a clear view of all the related records you’ll need to include in your deployment.

    • Once you have your data templates ready, ensure that you review the relationship diagram from the primary data template to confirm that you have included all related records.

  • Establish a naming nomenclature for your data templates:

    • If you have multiple users creating data templates in the same org, we recommend that your users prefix the data template names with their user name initials.

    • Similarly, if you create a data template to move test data from your production to your sandbox environment, you can prefix the template name with ‘Test Data.’

    • If you’re creating multiple versions of a data template, ensure that you append the version number to the template name. You can specify the changes made under the template description.

    • If you have created or cloned a template for a specific user story, append the user story number to the template name.

  • Create accurate filters, especially for configuring data.

  • Selecting related objects in templates: you cannot select the same template twice.
    Example: Let's assume you have an Account template and a related Contacts template that you are about to deploy. And you have selected Contacts from the Child Objects tab of the Accounts template. You’ll need to skip setting Accounts as a parent object in the related Contacts template. Not doing so will trigger an infinite loop between the two object definitions and throw an error.

  • Working with test data: we recommend that you move the most recent records in your production org as they are bound to have the latest features that you can work with. You can filter your recent records by creating a date filter: Created Date = Last Quarter.

  • Cloning a data template: you can clone an existing data template and create new fields in an object or set different filters. Doing so lets you maintain different versions of the data template and track changes under the template description box.

  • Moving sensitive data to sandbox: if you need to test sensitive data in your sandbox, you can leverage Copado’s Scramble Value and the Scramble With Format options. We’ll replace the original value with a random one.

  • Organize templates that belong to a particular application or object by creating list views: you can create a list view for CPQ templates by filtering out the copado__Main_Object__c fields that start with “SBQQ__” (namespace for the CPQ package.)

  • Use data sets if you have to work with the same data frequently: if you’ve to move the same data often between different environments for testing purposes, we recommend using data sets.

  • Use the data commits feature in a multi-user environment: deploy records from a committed version if you have multiple developers working on the same set of data records to maintain the version history of your changes and prevent conflicts and overwrites.

Data Quality

While working with a release management tool like Copado, it is essential to maintain good quality data. You’ll have to ensure that the changes moving through your pipeline have passed relevant quality gates, and your sandboxes are updated with the latest changes flowing from your production org. To do this, we’ve recommended best practices for maintaining data consistency and quality:

  • External Id field on objects: create External Id fields with unique values for different objects you are working with to ensure that records are not duplicated during deployment. Use Copado's record matching functionality to automatically populate a value in the External Id fields that are empty.

  • Validation rules: use data validation rules to maintain the data structure. Defining validation rules let you enforce specific requirements that the users need to adhere to while saving a record. To learn more about different validation rules, check out the Salesforce article on Examples of Validation Rules.

    • Before you deploy validation rules or triggers to your destination org, ensure that your existing data is compliant with the same.

  • Help text and Hint text: ensure that you add relevant help and hint texts to your fields to input data in alignment with the data validation rules.

  • Clean up your data: use apps that let you deduplicate rows and enforce duplicate/matching rules using unique values.

  • Keep your sandboxes in sync: update your sandboxes with the latest data from your production org to avoid deployment errors.

Did this answer your question?