Answers.Body: <p>The External ID (<code>external_identifier</code>) is maintained in the database with a unique index, so any attempt to enter a duplicate value will take an error.</p>
  
  <p>The <code>external_identifier</code> itself is simply a variable character string of 64 char in length (<code>varchar(64)</code>).  As such it cannot auto-increment.  </p>
  
  <p>Remember, the <code>external_identifier</code> is designed to contain an identifier of the contact that might originate in a separate system.  In practice, it is most common to use it when migrating from some other CRM system into CiviCRM, wherein the other systems identifier is stored in the External ID.   This can be invaluable for audit purposes.</p>
  
  <p>If you are looking for an auto-incremented identifier, you should consider using the <code>contact_id</code>.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-06-17T03:41:44.693Z
Answers.Text: thank you for the answer. For my organization, I want to store data of visitors, students, professors, scientists, members. While members have ID's in our previous system, others don't carry any such IDs.  I am caught up between whether to use External ID to store the previous system ID or to create a custom field under civiMember? any suggestions?
Answers.UserDisplayName: Parthibaraj Rajasekar
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-06-19T12:58:23.517Z
Answers.Text: Without knowing your particulars, I would suggest that you store the previous system ID in the External ID.  That's really what it's for.  Everything else should fit nicely into custom data sets I imagine. The only gotch is probably if you have different identification systems across the various originating data sources.  Then, it usually helps to add a prefix to the external id to make it unique, but still auditable.
Answers.UserDisplayName: DaveD
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-06-16T16:52:18.263Z
Answers.LastActivityDate: 2017-06-16T17:44:06.193Z
Answers.LastEditDate: 2017-06-16T17:44:06.193Z
Answers.UserDisplayName: DaveD
Body: <ol>
  <li><p>Is External ID Unique? will it automatically check for a duplicate External ID when the attempt is made to enter into database?</p></li>
  <li><p>Can External ID be auto incremented whenever an individual gets added?</p></li>
  </ol>
  
Tags: <contacts><database><external-id>
Title: questions on External ID
ThreadText: # questions on External ID
  
  (Asked by: username_0 on 2017-06-16)
  
  1. Is External ID Unique? will it automatically check for a duplicate External ID when the attempt is made to enter into database?
  2. Can External ID be auto incremented whenever an individual gets added?
  
  **Tags:** contacts, database, external-id
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2017-06-16. Score: 4 | Accepted answer
  
  The External ID (`external_identifier`) is maintained in the database with a unique index, so any attempt to enter a duplicate value will take an error.
  
  The `external_identifier` itself is simply a variable character string of 64 char in length (`varchar(64)`). As such it cannot auto-increment.
  
  Remember, the `external_identifier` is designed to contain an identifier of the contact that might originate in a separate system. In practice, it is most common to use it when migrating from some other CRM system into CiviCRM, wherein the other systems identifier is stored in the External ID. This can be invaluable for audit purposes.
  
  If you are looking for an auto-incremented identifier, you should consider using the `contact_id`.
  
  > **Comments:**
  > **username_0**: thank you for the answer. For my organization, I want to store data of visitors, students, professors, scientists, members. While members have ID's in our previous system, others don't carry any such IDs.  I am caught up between whether to use External ID to store the previous system ID or to create a custom field under civiMember? any suggestions?  
  > **username_1**: Without knowing your particulars, I would suggest that you store the previous system ID in the External ID.  That's really what it's for.  Everything else should fit nicely into custom data sets I imagine. The only gotch is probably if you have different identification systems across the various originating data sources.  Then, it usually helps to add a prefix to the external id to make it unique, but still auditable.  
  
  ---
  
  