When we load data, we need to load it in the order of dependencies; for example, before we insert Opportunities, we must first insert the Account records.
Another example is to load Opportunity Line Items. We must first load both the parent records of Opportunity as well as Price Book and its Price Book Entries.
Salesforce automatically manages the system fields, such as Created Date, Last Modified Date, Last Modified by, and Created by. Normally, we are unable to set or change these values for audit integrity purposes. However, an administrator can contact Salesforce Support to enable the Create Audit Fields feature for a limited time to allow these fields to be set on the create operation only.
To find more details about how to create Audit Fields, go to https://help.salesforce.com/apex/HTViewSolution?urlname=Considerations-before-having-Create-Audit-Fields-enabled&language=en_US.
Some of the important features of modifiable system fields are as follows:
- The fields can be modified only once in the lifetime of the initial insert.
- They are accessible through the API, that is, the data loader.
- All custom objects can have modifiable system fields; however, not all standard objects can have modifiable fields.
- Account, opportunity, contact, lead, case, task, and event can have modifiable fields.
- The fields are read-only for existing records. If you need to change these system fields for the existing records, then you must export the data, delete the Salesforce copies, then reimport the new data.
We can perform four different data manipulation operations using the API. The data is inserted in CSV format. The records to be manipulated are created as rows and the field API names are created as columns.
The INSERT operation allows us to insert bulk data into an object. The records are inserted without a RecordID.
The UPDATE operation updates the record on the basis of the Record ID. If we do not provide the Record ID, the update operation will fail. The DELETE operation requires the Record ID and deletes those records. Unlike the traditional SQL systems, we cannot directly provide a delete query, such as DELETE FROM account WHERE name = 'Acme'. Instead, we must first query for the Acme account and then issue a delete for that ID.
We also have a UPSERT operation, which is a combination of insert and Update operations. The records that need to be updated are provided with the Record ID or External ID, and the records that do not have any Record IDs are inserted. As compared to traditional SQL databases, UPSERT is analogous to the MERGE statement, which will update a record that matches the criteria else insert a new record if no match is found. The UPSERT operation helps avoid duplicates based on IDs or external IDs. If more than one record is matched, an error is reported.
When we are migrating data from an external system, we can link it with Salesforce records using an external ID. A custom field can be marked as an external ID to identify the primary keys of the legacy system. The Text, number, and e-mail fields can be flagged as external IDs.
Fields marked as external IDs are indexed and are available on all the objects that can have custom fields. External ID fields are searchable and appear in search queries.
An object can have up to seven external ID fields.
The general library wishes to migrate the media information from the spreadsheets they are currently using. They have a field called Media Number in the spreadsheet, which is a unique identifier (a primary key) in the current system. Migrate the data into the media object and avoid duplicates.
To migrate the data from the spreadsheet, we first need to create an external ID field in the media object. We discussed how to create a custom field in the object in Chapter 2, Creating a Database on Force.com.
Create a Media_number field in the media object in Salesforce; the field can be a text field. Check the flag for the external ID to flag it. While loading the data, use the Media_number field and use upsert to load the data.