Skip to content
This repository was archived by the owner on May 15, 2025. It is now read-only.

Object Mappings in JSON

Anoop Singh edited this page Sep 11, 2018 · 1 revision

Object Mappings in JSON

Objects in Salesforce can have are lookups, master-detail and hierarchical kind of relationships.

One of the input for this migration tool is that you need to create object mappings in JSON format (JSON Mapping Dictionary) for the objects that you want to migrate records for. In the following sections, we will cover some of the possible object mappings for different kind of simple and related objects.

Simple object - JSON Mapping

The JSON object mapping for a simple object will look like this. In this below example, lets assume that Pricebook2 has no other relationships. The tool will migrate all Pricebook2 records from source org where IsStandard is not equal to true, to the target org.

[
  {
    "parent": "Pricebook2",
    "where": "IsStandard != true"
  }
]

Object with lookups - JSON Mapping

In this example we will cover how to related the lookup objects in a JSON object mapping. Lets say, you want to migrate PricebookEntry records but PricebookEntry has lookups to Pricebook2 and Product2 objects. Create "lookups" structure that will identify the lookup field name, lookup object and a composite key to uniquely identify the lookup record.

To filter certain records, use "where" filter in JSON. If you don't want to migrate certain fields, make them part of unmappedFields array.

[
  {
    "parent": "PricebookEntry",
    "where": " IsActive = true AND Pricebook2.IsStandard = true ",
    "unmappedFields": ["ProductCode", "Name"],
    "lookups": [
      {
        "lookupMappedField": "Pricebook2Id",
        "lookupObject": "Pricebook2",
        "keys": [
          "Name",
          "IsActive",
          "IsStandard"
        ]
      },
      {
        "lookupMappedField": "Product2Id",
        "lookupObject": "Product2",
        "where": "Name != null",
        "keys": [
          "Name"
        ]
      }
    ]
  }
]

Even though you can go about your org to org migration without external ids, but there are couple of cases where you have to have external id.

  • Hierarchical relationships
  • You want to avoid duplicates and have no other approach to avoid duplicates

Hierarchical relationships

Hierarchical relationships are handled using an insert and update, for that reason, its a requirement to have external id for hierarchical objects. e.g. in the below relationship, Approval_Process__c has a self relationship. The JSON to successfully migrate the Approval_Process__c and self lookup will look something like below.

Note the externalIdField and refresh attributes in JSON. Set externalIdField to your external Id field and set refresh to true.

[
  {
    "parent": "Approval_Process__c",
    "externalIdField": "ExternalId_Key__c",
    "refresh": true,
    "lookups": [
      {
        "lookupMappedField": "Entry_Criteria__c",
        "lookupObject": "Approval_Process__c",
        "keys": [
          "ExternalId_Key__c"
        ]
      }
    ]
  }
]

You want to avoid duplicates and have no other approach to avoid duplicates

Since you can easily integrate this migration tool in your CI/CD. You may run the migration multiple times in a target org, which is fine, but if you don't have external id, you may see duplicates in target. If for some reason, you can't have external id and would like to avoid duplicates in the target org, then you can take couple of approaches.

  • Before migration, delete the records from target org. Tool provides you a way to delete the records from target org based on your JSON mapping.
  • Or, you can run the migration selectively so you just migrate only the records that you know won't cause duplication in the target. For that, you can use "where" attribute in JSON.
[
  {
    "parent": "Pricebook2",
    "where": "IsStandard != true"
  }
]

2. Lookups

3. Avoid certain fields in migration

4. Set certain fields to null in Target org

5. Data Masking

Clone this wiki locally