Deploying relational data between Salesforce orgs can be challenging when you’re navigating how and when Salesforce record IDs change. If you’re not careful, you may end up with duplicate records… and a lot of extra work.
In this blog, we discuss when record IDs are different and when they remain the same. We also explain how to prevent duplicate data records with Prodly.
Salesforce assigns a unique record ID to each record when you import it into an org. It doesn’t matter whether you import it using manual entry, a simple single-object data loader, or a sophisticated data migration tool like Prodly.
Salesforce breaks the association between orgs. When you move a data set from one org to another, Salesforce assigns a new record ID to each record in the data set. Think, for example, of when you move data from sandbox to production or from production to sandbox.
During a full or partial sandbox refresh, Salesforce copies Salesforce record IDs from production to the sandbox. Because it copies the record IDs, they remain the same.
Salesforce also copies record IDs when you refresh a Developer or Developer Pro sandbox for standard objects like Products, Price Books, Price Book Entries. It also copies them when you clone a sandbox.
Even when it copies record IDs, Salesforce still breaks the association of the records between orgs. Because the orgs aren’t synced, changes in one org after the refresh will not be reflected in the other.
When you move updated data from a sandbox to your production org, Salesforce assigns a new record ID to each record. If you haven’t taken any precautions against duplication, Salesforce inserts the data set from the sandbox without updating any of the old records in production.
Many Salesforce admins get frustrated with the process of deploying data between orgs without creating duplicate records.
Oftentimes, they assign external IDs to each object in a data set to associate the object with a parent object outside Salesforce. If you’ve used this technique before, you know it’s laborious, time consuming, and prone to error.
Prodly eliminates this time-consuming manual task with its exclusive automatch feature. When you migrate data, the automatch manager automatically creates an association between source and destination org Salesforce record IDs. It then stores this information in the Prodly app.
This eliminates the need to manually create and maintain formal external IDs on every record. And that saves you a lot of time and work.
When you deploy data between orgs, Prodly first checks to see if the source records have a matching record with the same Salesforce record ID in the destination org.
If there isn’t a match, Prodly checks its automatch database to see if the records are the same but the IDs are different. If Prodly doesn’t find a match, it creates a new record. This prevents duplicates during a data deployment.
It’s best to set up the automatch manager when you move data from an existing org to an empty one, from a sandbox to a production org, or after a sandbox refresh.
However, you can still set up automatch during a development cycle. This involves a few extra steps to consolidate data and ensure the automatch manager accounts for all the matching records.
Learn more about setting up the automatch manager and about automatch in general on our help site.
Successful relational data deployment starts with understanding when Salesforce record IDs change and when they’re copied.
Prodly takes matching and changing Salesforce record IDs into account when you deploy relational data with the automatch manager. This solves the problem of duplicate data records without extensive use of external IDs.
The gold standard for documenting SOX in Salesforce CPQ!
