Deploy Object Data

Deploying store object data from a Salesforce source org to a target org involves careful planning and execution to ensure data integrity and system stability. Here’s a general process to follow.

Prepare data.

a. Make sure that the data is accurate and up to date. Cleanse the data in the sandbox environment.

b. Remove test data that ‌you don’t want deployed to the target org.

c. Identify data dependencies and relationships to make sure that related records are deployed together.
Map the fields from the sandbox to the target org.

a. Make sure that the data is directed to the correct fields.

b. Before deployment, create the custom fields or objects that ‌don’t exist in the target org.
Back up your current target org data before importing new data.

a. This backup is crucial for restoring the system in case the deployment causes unexpected issues.
Choose a data deployment tool that’s designed for bulk data operations, such as Salesforce Data Loader.

a. Configure the tool with the target org’s credentials and endpoint.
Test in a full copy source org.

Perform a test deployment in a full copy source org that is a replica of the target org to identify potential issues before they affect the target system.
Migrate the data

a. To minimize the impact on users, schedule the deployment during off-peak hours.

b. Use the Data Loader or deployment tool to insert, update, or upsert the data from the source org to the target org.

c. Monitor the deployment process for errors or issues.
Validate the data in the target org.

a. Make sure that all records were deployed successfully and that relationships are intact.

b. Check the error logs, and address records that failed to deploy.
Test the deployed data.

a. Thoroughly test the target org to make sure that the deployed data is functioning as expected.

b. Test integrations, workflows, and processes that rely on the deployed data.
Review and clean up the data.

a. Check for duplicate records or data inconsistencies. Duplicated records can be created during the deployment.

b. Clean up unnecessary data that was inadvertently deployed.
Go live and monitor for issues.

a. Monitor the target org for post-deployment issues and be prepared to respond quickly to problems.
Inform stakeholders of the deployment’s completion.

Making sure that the data is clean, accurate, and formatted correctly smooths the transition from one environment to another. Use these guidelines to prepare your data for deployment.

Data assessment—Review the existing data structure, including all objects, fields, records, and relationships. Identify which data is relevant and must be deployed, including historical data that’s necessary for business operations or compliance.
Data cleanup—Remove unnecessary, outdated, and duplicate data from the source environment. Correct data inaccuracies, such as misspellings or incorrect field values. Standardize data formats. Archive or delete outdated or irrelevant data that doesn’t need to be deployed.
Data validation—Make sure that all data complies with the validation rules in the target environment. Check for mandatory fields and make sure that they’re populated with valid data.
Data dependencies and relationships—Map out the relationships between different datasets, such as parent-child relationships, lookups, and main-detail relationships. To maintain data integrity, plan the deployment order based on these dependencies. For example, deploy parent records before child records.
Field mapping—Create a field-mapping document that aligns the source fields with their corresponding target fields. Note transformations that must occur during the deployment process. For example, determine how to handle fields that don’t have a direct match.
Record IDs and references—Decide how to handle Salesforce record IDs, external IDs, and other unique identifiers. Ensure that the correct record IDs are used.
Data formatting—Format data to match the target system’s requirements, including dates, numbers, and strings. Ensure that multi-select picklist values, checkbox fields, and other special field types are formatted correctly.
Data extraction—Extract the data from Salesforce Commerce into a format suitable for deployment, typically CSV files. Ensure that the extraction process captures all necessary fields and records. To extract the data from the source environment, use a tool like Salesforce Data Loader.
Data segmentation—If the dataset is large, segment it into smaller, manageable batches. Segmentation can help with troubleshooting and reduces the risk of system performance issues during the deployment.
Test deployment—Perform a test deployment with a subset of the data in a full copy sandbox or developer sandbox. Address issues that arise during the test.
Data backup—Back up the data in both the source and target systems to ensure that you can restore the original state if necessary.
Security and compliance—To ensure that sensitive data is handled correctly during the deployment, review the security settings. Make sure that field-level security, sharing rules, and other security settings in the target environment allow for the proper visibility and access to the deployed data. Check that the deployment process complies with relevant data protection regulations.
Deployment documentation—Document the entire data preparation process, including field mappings, data dependencies, and special handling instructions. This documentation is valuable during the deployment and for any troubleshooting that is required afterward.
Stakeholder communication—Share the deployment documentation with all stakeholders for review and feedback, and update the documentation as needed..
Final approval—Obtain final approval from the project manager, data owner, and stakeholders. Ensure that all involved parties are informed about the deployment schedule and process.
Detailed deployment plan—Develop a comprehensive deployment plan that includes timelines, resources, roles, and responsibilities. Outline the order in which data is deployed, considering dependencies and relationships. Detail the sequence of migration steps, including data extraction, transformation, loading, and validation phases. Include contingency plans for handling potential issues during the deployment.
Scheduling—Plan the deployment during a period that minimizes impact on users, typically during off-peak hours or a scheduled maintenance window. Communicate the deployment schedule to all stakeholders and ensure that support staff are available during and after the deployment.
Execution—Monitor the deployment closely, logging all actions and issues that arise. Use the prepared documentation to guide the deployment and resolve issues.
Post-deployment validation and testing—Validate the data in the target system to ensure that it’s been loaded correctly and completely. Conduct thorough testing to confirm that the data works as expected within the new environment. To ensure that the deployed data meets user needs and expectations, involve end users in the validation process.
Post-deployment issues—Address issues identified during the validation and testing phase. Update the deployment documentation with changes made during this phase for future reference.

Field mapping involves matching the source data fields to their corresponding target fields. Proper field mapping ensures that the data is imported correctly into the new system. Use these guidelines to prepare and complete field mapping.

Understand the source and target data models.
- Familiarize yourself with the data schema of both the source and target systems. Identify the relevant objects and fields in the source system that correspond to the Salesforce objects.
List all fields from the source system, including custom and standard fields, that must be deployed. I
Identify the target fields.

Determine the corresponding fields in Salesforce where the source data should reside. I
Create a mapping document.

Use a spreadsheet or a data-mapping tool to create a field-mapping document. List source fields in one column and the corresponding target fields in another.
Map the fields.

a. Begin with standard fields that have direct equivalents between the systems. For example, Product Name, Price, and SKU. For fields in the source system that don’t have a standard equivalent in Salesforce, determine if there are existing custom fields that you can use or if you need to create new custom fields.

b. Map the custom fields. Make sure that equivalent fields exist in the target system or create them if necessary.

c. Identify fields that require data transformation. For example, combine first and last name fields into a full name field, and convert date formats. Document the transformation rules and logic in the mapping document.

d. Map complex relationships. Examine the relationships between records in the source data, such as parent-child links between products and categories or orders and customers. Ensure that these relationships are preserved in the target system by mapping the related fields correctly, such as lookup or main-detail fields in Salesforce. Plan the sequence of data loading to respect these relationships so that parent records are loaded before child records to maintain referential integrity.

e. Make sure that the Salesforce data types can accommodate the data from the source fields. For example, for text, number, date, and field lengths, adjust the data or the Salesforce fields as necessary.

f. Map default values.If the source system contains fields with default values that aren’t present in the data extract, specify these default values in the mapping document.

g. Ensure that picklist and multi-select fields in the source system have equivalent values in Salesforce. Map or transform values as needed to fit the Salesforce environment.

h. Handle unique identifiers. If the target system requires matching external IDs, map these fields to ensure that the data is included in the migration. Establish a method for generating new unique identifiers if they can’t be preserved or if the target system generates new ones upon data import.

i. Set default values and null handling. Decide if empty or null source fields can be set to default values in the target system or left blank. Document the default values for fields that require them in the target system.
Validate field mappings with stakeholders. Make sure that all business requirements are met and that the data is usable in the target system. Adjust the mappings based on feedback and revalidate as necessary.

Salesforce Data Loader bulk imports or exports data. Use it to insert, update, delete, or export B2B store object data from a source org to a target org. Use these guidelines to export and import data with Data Loader.

To download and install the Data Loader, go to https://developer.salesforce.com/docs/atlas.en-us.dataLoader.meta/dataLoader/data_loader_intro.htm.

Prepare object data.

a. Ensure that the data in your sandbox is clean and ready for migration.

b. Remove test data that you don’t want deployed to the target org.

c. Identify data dependencies and relationships to ensure that related records are deployed together.

d. Map the fields in your CSV file to the fields in Salesforce. See Define Data Loader Field Mappings.
- Data Loader can auto-match fields by name, or you can manually map them.
- Save your mapping to a file for future use if you plan to perform this operation regularly.
Export 0bject data from the source org to a CSV file.
- See Export Data from Salesforce.
Prepare the target org.

a. Log in to your target org and ensure that all custom fields, objects, and dependencies are present and match the source configuration.

b. Back up your target org data before importing new data.
Prepare the CSV files.

a. Review the CSV files exported from the source org and make any necessary adjustments to the data, such as updating record IDs to match the target org or removing fields that aren’t needed. See Data Mapping.

b. Ensure that the CSV files are properly formatted and encoded (UTF-8 is recommended).

c. Make sure that the files have the necessary headers that correspond to the Salesforce field API names.
Test the import with a small dataset.

a. Use Data Loader to import the test data into the target org. See Insert, Update, or Delete Data Using Data Loader.

b. Import data in the correct order to maintain relationships, for example, import Accounts before Contacts.

c. Verify that the test records are imported correctly and resolve any issues. See Review Data Loader Output Files.
Deploy the object data.
- Data Loader supports batch mode operations from the Windows command line. See Run In Batch Mode (Windows Only).
Verify the import.

a. Review the Data Loader success and error files for which records were imported successfully and which weren’t.

b. Investigate and resolve errors that occurred during the import. See Review Data Loader Output Files.
Review the imported records.

a. Log in to the target org and manually check the imported records to ensure that they are correct.

b. Validate that relationships between records (like parent-child relationships) are intact.

c. Perform any necessary post-import adjustments in the target org.
Test the migration.

a. Make sure that the imported data works correctly within the target org.

b. Test all related processes, workflows, and integrations.