![]() |
|
![]() |
About Record Duplicates and External IDsWhen you import records, you can choose to handle duplicate records in these ways:
Your CSV file might have External IDs, which are generated by many software systems. Using External IDs makes importing from external systems easier, where a primary key/foreign key relationship is represented by storing IDs in the related file. If you have External ID codes for each of your records, you can use the Import Assistant to update fields in those records (except the External ID field). If you do not have External ID codes, you can only update those fields that are not used for duplicate checking. To update records:
When you use the Import Assistant to update records, only fields that you map in the Field Mapping step are overwritten. Therefore, if you have fields that do not need to be updated, and they are not required for duplicate checking, you do not have to map those fields. If External IDs exist and you have mapped them during the import process, the application uses them to determine if a record is a duplicate. When importing other record types, you can use those External IDs as references so that the associations are carried over to Siebel CRM On Demand. For example, if you have an account_id column in your account.csv file, you want to map it to the "External Unique ID." When importing contacts, if your contacts.csv file contains a contact_id column (the unique ID for the contact) and an account_id column (a reference to the IDs in the account.csv file), you should map the contact_id to "External Unique ID" and account_id to "Account External ID." During the import process, the application checks the account_id field in each contact record to determine the existing account and link the account to the contact. If no External IDs exist or you don't map External IDs in your file to the External ID fields in the application, the application determines duplicates by comparing certain fields. The following table lists the fields used for determining record duplicates:
CAUTION: When updating files, it is recommended that you map either the External ID or the other set of fields for determining duplicates; if you map both of them, you risk overwriting fields used for duplicate checking that you might not want to overwrite. For example, if you map the External ID, Account Name, and Location when updating account records, and a duplicate is found based on the External ID, the Account Name and Location overwrite the existing values in the database. If no duplicates are found based on the External ID, the system checks for duplicates based on Account Name and Location, and if found, overwrites the External ID in the database. Account Import and External ID SummaryWhen importing accounts, you specify how you want the application to handle duplicate records:
After selecting the behavior, you have the option of mapping fields, including these two external IDs available with account imports:
The behavior surrounding each of these external IDs is independent of each other. Scenarios for External Unique IDsScenario A - External Unique ID is not mapped Duplicate checking is based on Account Name and Location. If a duplicate is found, the behavior is determined by the selected duplicate checking option. Scenario B - External Unique ID is mapped Import first tries to find a duplicate record using the External Unique ID.
Scenario C - External Unique ID is not Mapped The Account Name and Location are used to perform duplicate checking.
Scenarios for Parent Account External IDsThe Parent Account External ID is only used to set the associated Parent Account Record. It has no impact on duplicate checking or updates. Scenario A - Parent Account External ID is Mapped Import uses the Parent Account External ID only to determine the Parent Account.
Scenario B - Parent Account External ID is not Mapped Import uses the Parent Account Name and Parent Account Location to determine the Parent Account.
| ||||||||||||||||||||||||||||
Published 05/11/2007 |