Composite External ID keys.

Table of Contents



Overview ⇧

Purpose: This feature enables the binding of source and target records by generating a "virtual" External ID field.

This virtual ID is formed by concatenating multiple field values, facilitating operations where unique identifiers are not present in the target object.

Use Case: Consider a Description object that lacks a unique field and is associated with two parent objects, Article and Language. Each Article can have multiple Descriptions, each in a different Language. Both Article and Language have unique Names.

Scenario: If you need to perform an upsert operation on the Description object, direct binding of the Description records isn't possible. Instead, you can bind them indirectly through their parent objects.

Configuration Example ⇧

To set up this process, you would define the Description object in your migration script as follows:

objects: [
    { ... },
    { ... },
    {
        "query": "SELECT Id, Name, Article__c, Language__c FROM Description__c",
        "operation": "Upsert",
        "externalId": "Article__r.Name;Language__r.Name"
    }
]

Explanation: In the script above:

  • The query selects the necessary fields from the Description object.
  • The operation specifies an upsert action.
  • The externalId defines a virtual formula that combines the Name fields of the Article and Language objects. This combination serves as a unique identifier during the upsert operation.

How It Works ⇧

During the data migration process, the system internally generates a virtual formula field. This field doesn't exist in the actual metadata of the Description object but is constructed by concatenating the Name values of the associated Article and Language. This virtual field is then used to uniquely identify and bind records.

Flexibility: You can concatenate an unlimited number of fields using a semicolon to separate each field, tailoring the virtual External ID to fit complex data structures and relationships.

Last updated on 20th Apr 2024