One of the problematic issues during data migration is correct migration of related data. For Salesforce objects this task is complicated with a specific nature of data storage organization in Salesforce. Relation between objects in Salesforce is based on auto-generated columns (object IDs), and therefore, it is difficult to correlate a relation between tables in a local storage and a relation between Salesforce tables.

One of possible solutions to this problem is using External ID. To a Salesforce object being referred (i.e. a master object), an External ID column is added; this External ID column is correlated with a unique column of a local referred (i.e. master) table.

Thus, using this approach, you can migrate related tables from the local data source to Salesforce objects keeping the relations, i.e. Devart Salesforce Destination component allows performing insertion of related data on the basis of External ID. This approach can be inconvenient due to the fact that it requires modification of the existing Salesforce objects (adding the External ID column) and of the corresponding column in the local data source, as well as their mandatory usage during data migration.

In Devart Salesforce Destination component another approach can be used, that is specific for our product, and is implemented through ID caching. This means, we store auto-generated IDs in the local cache, and these IDs, in their turn, are associated with the unique key in the local table being migrated. As a rule, this unique key in the local table is its primary key.

During migration of a related table we replace the foreign key value of the local table with the actual ID value of the Salesforce object (referred by our child object).

For details on implementation of these approaches refer to topics ExternalID and CachedID.