Custom objects and fields are usually created to support the customisation of existing Salesforce functionality, or to create entirely new functionality that has not yet been thought of.
In this short tutorial, we’ll walk through the basics of creating custom objects and fields.
The requirement for these are usually determined by application functionality rather than the requirements of a Data Migration or Data Integration project. These projects are usually only required to read or write these objects and fields, to meet a pre-defined functional need.
One exception to the above, is the use of External IDs. External IDs are custom fields that act as a unique key that can be referenced back to an external system.
This is of particular interest to Data Migration and Data Integration projects, as they usually require a reference that links back to an originating system either for technical reasons, or for purposes such as data lineage and auditing.
External ID Attribute on Custom Fields. In the Salesforce CRM user interface, you can identify up to seven (7) custom fields on an object as being an external ID field. The field type must be a text, number or email field. An external ID contains record IDs from a system outside of Salesforce.
In this article, we’ll look at the use of External IDs named UUID. These will hold a Universally Unique Identifier (UUID). In the tutorial Salesforce Data Migration, a UUID is used to support data migration, providing a reference back to source data for technical, data lineage and auditing purposes.
Often, a Primary Key or Unique Identifier from a Source System is used as a the External ID. This is, arguably, bad practice as it can often be problematics to persist legacy keys, especially if you have data arriving from multiple sources where there may be a key collision. Even when you are using a pseudo-generated key such as UUID, there should alway be a route back to the originating data.
Custom Field Name API Name Type Length UUID UUID__c Text 36