Handling of the RecordType.

Table of Contents



Overview ⇧

Purpose: This feature facilitates the seamless migration of RecordType attributes with records, ensuring that the RecordTypes in the target environment match those in the source.

It handles complexities such as multiple RecordTypes with the same DeveloperName, which can create confusion in the target environment.

Use cases ⇧

To maintain the integrity of RecordTypes during data migration:

  • Basic Usage: To simply migrate records while preserving their RecordType, include the RecordTypeId field in your query. The plugin will automatically handle the migration of the RecordType ID associated with each record.

  • Advanced Customization: For more complex scenarios, where customization of the RecordType export is needed, you can directly include the RecordType object in your export.json. This allows for more control over which RecordTypes are migrated and how they are identified in the target environment.

Full RecordType Object Definition ⇧

Here's an example of how to include a RecordType object within an export.json to ensure only active RecordTypes are migrated:

"objects": [
    {
        "query": "SELECT Id FROM RecordType WHERE IsActive = true",
        "externalId": "DeveloperName;NamespacePrefix;SobjectType"
    }
]

Configuration Details ⇧

  • Active RecordTypes Only: This configuration includes only RecordTypes that are active. Records linked to inactive RecordTypes will be reassigned to the default 'Master' RecordType in the target environment.

  • Composite External ID: The externalId field uses a composite format combining DeveloperName, NamespacePrefix, and SobjectType. This composite ID helps in accurately matching RecordTypes across different environments, especially when there are RecordTypes with the same DeveloperName.

  • Default Value: The "DeveloperName;NamespacePrefix;SobjectType" format is also the default setting when the RecordType section is not explicitly included in the script, and you only add RecordTypeId in your query. This setting is recommended for most migrations as it ensures consistency across environments.

  • Custom External ID: You have the option to define alternative external ID keys based on your specific requirements.

  • Customizing SOQL Query: The SOQL query for RecordType can be customized to fit specific needs, such as including only certain types of RecordTypes or filtering based on other criteria.

Key Considerations ⇧

  • Ensure that the SOQL query for the RecordType object aligns with the needs of your migration strategy, particularly in terms of which RecordTypes need to be included based on their active status or other attributes.
  • When setting up your export.json, consider how RecordTypes with the same DeveloperName are managed to avoid any issues in the target environment.
Last updated on 20th Apr 2024