Welcome to the magical world of deploying records with relationships! ✨ This topic is near and dear to our heart (us being ATG, FuseKit’s creator and a CPQ and Billing consulting company), since Salesforce CPQ and Billing configuration is mostly done in record data and contains ALL the relationships. It’s useful for plenty of other scenarios, though, like if you want to migrate Accounts + Contacts, or Products + Pricebook Entries.
Buckle up because we are about cruise 🚗 through an example of using FuseKit’s Deploy External ID, Query, and Load tools to complete a seamless deployment of Accounts and Contacts. FYI - we will not be providing click-by-click instructions since you can find those directly on the Deploy External ID page:
All about that External ID
Remember how we said the deployment would be seamless? That’s mostly due to External IDs, which are used to reconnect relationships between records during the migration. You might be thinking to yourself, “Isn’t that what Record IDs are for?” 🤔 You are on the right track, but remember that every time that you migrate data to a new environment, Salesforce will automatically populate the Record ID field with a new value – leaving the poor child records unable to find their parent! ☹ Because of this, we create a custom External ID field and stick a unique value in it that will persist from the source environment to the target environment without Salesforce overwriting it. Keeping it simple, whenever you see a lookup field on a record, you should expect to use the Deploy External ID tool.
Let’s Get Crackin’
Step 1: Determine what to Migrate
So, to start off our example, let’s figure out what we need to migrate. We know that we want to move 5 Accounts 🏠 which were created today, along with their related Contacts 👨💼, from our Dev environment to our Testing environment. We also know that the Contact records have a lookup to the Account. Because of this, we will need to create an External ID field on the Account, so that when we load the Contacts in, they are able to find the correct Account using the value in that field.
Step 2: Create External ID field
Let’s use the Deploy External ID feature to create the External ID field on the Account record in both of our environments (saving us from having to deploy the field 👏). Pro tip: You only need to create the External ID field on the object once. This step can be skipped for any future migrations.
Step 3: Populate External ID on Records
Next up, we are going to use the Deploy External ID feature again, this time to populate the value of the External ID field for all of the Accounts in the Dev (source) environment. If you already had an External ID field on this object (because you’ve migrated records from it before), you can use this tool to target 🎯 that existing field and populate External ID values on any new records which were created since your last migration.
Step 4: Query Records
Now that all of our Accounts have their External ID value populated, we can use the Query tool to extract all of the Account and Contact records. When doing this, make sure to select the External ID field on the Account, as well as the Account.External ID field on the Contact, by traversing 💃 the Account relationship.
Step 5: Load Records
So we’ve got our data files containing the External ID fields, which means we are ready to load baby! We will load in the Account records first, so that they’ll be ready to be mapped to when we load in the Contact records. When loading in the Contacts, be sure to check the auto-mapping and make sure the Account lookup mapping is pointing to the correct External ID field. (Not-so-pro tip: Make sure you’re loading to the correct environment 😉)
Step 6: Celebrate!
Just like that, our Accounts and Contacts have been reunited and can live happily ever after in our Testing (target) environment❤, and you my friend, can officially add ‘Matchmaker’ to your resume skills.