Sign up for weekly AppOps insights.

Sign up for weekly AppOps insights.

The ins and outs of Salesforce record IDs

Tori Bealer

January 22, 2019

What you need to know to successfully copy relational data from one org to another

Deploying relational data between Salesforce orgs can be a tricky process when you’re navigating how and when Salesforce changes the record IDs of your data. If you are not careful, you may end up with duplicate records or extra work. Let’s break down when record IDs are the same between Salesforce orgs, when they’re different, and how you can prevent duplicate data records with Prodly’s automatic duplicate prevention capabilities.

When Salesforce record IDs are different

If you’ve been developing in Salesforce for awhile, you may know that Salesforce assigns unique record IDs to each record when it’s brought into an org: it can be done through manual entry, a simple single-object data loader, or a sophisticated multi-object data loader like Prodly. You may also know that Salesforce breaks the association between orgs. Generally, this means that when a data set is moved from one org to another, Salesforce assigns a new record ID to each record in the data set. Examples of this change can be seen when data are moved from sandbox to production or from production to sandbox without a sandbox refresh.

When Salesforce record IDs are the same

While it might seem that Salesforce assigns new record IDs every time data are moved, this is not the case. During a full or partial sandbox refresh, record IDs are copied from the production org to the sandbox org. Record IDs are also copied when refreshing a Dev or Dev Pro sandbox for standard objects like Products, Price Books, Price Book Entries, or when a sandbox is cloned.

Even when record IDs are copied, Salesforce still breaks the association of the records between orgs. Because the orgs are not synced, changes in one org after the refresh will not be reflected in the other.

When updated data are moved from a sandbox to production org, Salesforce will assign each record a new ID. If no precautions have been taken against duplication when this move happens, Salesforce will insert the data set from the sandbox without updating any of the old records in the production org.

Solving the duplicate data problem

Deploying data between orgs without creating duplicate data records is a source of frustration for many Salesforce admins. Often times, the solution is to assign external IDs to each object in a data set to associate the object with a parent object outside of Salesforce. If this is a technique you’ve used before, you know that it’s laborious and mistakes can happen even with careful attention.

Prodly removes this time-consuming task by implementing virtual external IDs (VEID), exclusive to the Prodly cloud-based service. When data are moved, the VEID manager creates an association between source and destination org record IDs and stores this information in the Prodly cloud. This eliminates the need to manually create and maintain formal external IDs on every record.

When you deploy data between orgs, Prodly first checks to see if the source records have a matching record with the same ID in the destination org. If there is no match, Prodly checks its VEID database to see if the records are the same but the IDs are different. If Prodly does not find a match here, it goes ahead and creates a new record. This helps prevent duplicates in a data deployment.

Setting up the VEID manager is best when moving data from an existing org to an empty org, from a sandbox to a production org, or after a sandbox refresh, but VEID can still be set up during a development cycle with a few extra steps to consolidate data in order to ensure the VEID manager accounts for all the matching records. You can learn more about setting up the VEID manager, and about VEIDs in general, on our help site.

Successful reference data deployment starts with understanding when Salesforce record IDs change and when they are copied. Prodly takes matching and changing Salesforce record IDs into account when deploying relational data with the VEID manager, solving the problem of duplicate data records without extensive use of external IDs.