Basic examples.
Table of Contents
- Example 1. Handling circular references.
- Example 2. Transfer Accounts related to specific Contacts.
- Example 3. Limit Contacts to Specific Accounts and Vice Versa
- Example 4. Exporting Objects with Self-Reference Fields
- Example 5: Handling Geolocation Fields
Example 1. Handling circular references. ⇧
One of the main advantages of SFDMU is that it enables us to migrate complex data models with circular references without any data loss.
Here is a simple example of how SFDMU can insert objects that have circular references between them.
This configuration can be used for various data migration directions: org-to-org, org-to-csv, and csv-to-org.
{
"objects": [
{
"query": "SELECT Name, User_Account__c FROM Account",
"operation": "Insert",
"externalId": "Name"
},
{
"query": "SELECT Name, Account__c FROM User_Account__c",
"operation": "Insert",
"externalId": "Name",
"master": false
}
],
"excludeIdsFromCSVFiles": true
}
Below you can find an example CSV file that can be used as a data source for this configuration.
Account.csv
Name,User_Account__r.Name
ACC_10001,Test User Account
User_Account__c.csv
Name,Account__r.Name
Test User Account,ACC_10001
Notes:
- We set the
Name
field as the External Id for both objects, so you should provide external ID columns likeUser_Account__r.Name
andAccount__r.Name
to link records of these two objects. - Set "excludeIdsFromCSVFiles": true to avoid needing to provide explicit record IDs and lookup IDs in the source CSV file. Only values of external IDs are required.
- Setting "master": false for
User_Account__c
will force SFDMU to select only those User Account records that have parent Account lookup fields set.
Example 2. Transfer Accounts related to specific Contacts. ⇧
The example below transfers Accounts related to specific Contacts that already exist in the target org.
{
"objects": [
{
"operation": "Readonly", // Use existing Contact records to identify the related Account records for migration
"externalId": "LastName", // 'LastName' is used as the External ID instead of 'Name', as 'Name' is not a defined field for the Contact object
"query": "SELECT Id, AccountId FROM Contact WHERE LastName = 'Smith'"
},
{
"operation": "Upsert",
"externalId": "Name",
"query": "SELECT Id, Phone, TEST1__c FROM Account",
"master": false // Ensures that SFDMU only locates the Account records related to the specified Contacts
}
]
}
Example 3. Limit Contacts to Specific Accounts and Vice Versa ⇧
The following configuration transfers only the Contacts related to 10 selected Account records. This is achieved by setting "master": false
for Contact, without limiting Contacts via a WHERE or LIMIT clause.
{
"objects": [
{
"operation": "Upsert",
"externalId": "LastName",
"query": "SELECT Id, AccountId FROM Contact",
"master": false
},
{
"operation": "Upsert",
"externalId": "Name",
"query": "SELECT Id, Phone FROM Account LIMIT 10"
}
]
}
Conversely, the configuration below transfers only the Accounts that are related to 10 selected Contacts.
{
"objects": [
{
"operation": "Upsert",
"externalId": "LastName",
"query": "SELECT Id, AccountId FROM Contact LIMIT 10"
},
{
"operation": "Upsert",
"externalId": "Name",
"query": "SELECT Id, Phone FROM Account",
"master": false
}
]
}
Example 4. Exporting Objects with Self-Reference Fields ⇧
To transfer self-reference fields, include the respective lookup field in your query as demonstrated below:
{
"objects": [
{
"query": "SELECT Name, ParentId FROM Account", // Include ParentId, the self-reference field to the same Account object
"externalId": "External_ID__c" // Set External_ID__c as the external ID for the Account. Replace with the actual field name used for export.
}
]
}
Example 5: Handling Geolocation Fields ⇧
Geolocation fields end with __s
. Here’s how you can manage these fields in a configuration:
{
"query": "SELECT Name, Lat_and_Long__Latitude__s, Lat_and_Long__Longitude__s FROM Account",
"operation": "Upsert",
"externalId": "Name"
}
References: