How do you use an external ID in the import wizard to import child objects of a master/detail relationship?

Question

OK, I need to import a few thousand records and import wizard seemed like a good choice. First I did some accounts - that went smoothly. Next I went to import some custom objects that have a master/detail relationship with the Accounts.

(Sidenote: It's really weird that the import wizards for accounts and basically everything else is in two very different locations - took a while to figure out.)

Step 3 of the wizard asked me to specify relationships.

Which Account field are you including in your file to fulfill the Master/Detail requirement?

It listed 3 options - Account Name, Salesforce.com ID, and an external ID. I have an external ID defined on Accounts and that's what's in the database (And what I used when creating the accounts) so I chose that. Now that external ID isn't stored on the custom objects so I didn't select a field to store it to in the subsequent steps. Everything else went normally.

When I got the result email it said

Number of Custom Cases skipped because they had an incorrect Master/Detail relation: 943

(That's every single one of them.)

So what went wrong? Does that external ID have to be stored on the child object as well as the parent? They didn't really give me any more detail than that. I could probably rewrite the query to get the account name but that isn't stored on the child object either. I don't want to have to try and correlate the Salesforce.com ID.

Answer 1

It does not have to be defined on the child and the parent. The child will have the actual account relationship field (e.g., Account__c on your custom object, or whatever your child record is). The Account will have the External ID that identifies it. The child load file will then have the external ID in it instead of the Account ID. This is one reason for having an external ID, so that you can link these records without using the SF ID.

Assume that you have an external ID field called customId on the Account (or more generically the MasterObject). Here's what to do when you are importing the child:

1. Step 3 (I think?). Specify Relationships On the "Which MasterObject field are you including in your file to fulfill the Master/Detail requirement" select your customId field.

2. Step 5 (I think?). Field Mapping This is where it is not super obvious. The UI automatically maps the customID Import Field (i.e., CSV field) to the customID Salesforce.com field (i.e., Object field). That is NOT what you want. Instead change the Salesforce.com field to actually be the MasterObject field, eventhough the field in the CSV is not actually the ID of the MasterObject.

The key is the mapping of the customID field to the MasterObject field instead of accepting the default of it being mapped to the customID field.

You can do the same thing using the Data Loader. Instead of choosing Insert you must choose Upsert. See: https://developer.salesforce.com/docs/atlas.en-us.dataLoader.meta/dataLoader/?title=page/Additional_detail. The key here is doing an Upsert and then on the mapping page use relationship field, i.e., object__r:id_c .

(The above is similar to this post.)

Answer 2

In step 5 of your import (Field Mapping) did you map your Import field which contains the account external ID to the Account field? That needs to be done for the import to work properly.

Answer 3

For the import of your custom object records (in this case) you should select Salesforce.com ID to specify relationships. Being that your accounts have already been inserted and your custom object has a master detail relationship with the account object, you will need to use the Salesforce Account Id as your unique key for matching the custom object records with the appropriate parent account. If your account names are unique identifiers as well you could use that, but it is not best practice.

The external ID option would only be used if you actually had an external ID field on the parent object that matched up with some field on the child object you are importing. In that case, you could use that as a key to link the two objects in your data load.