Since voters can move, and a single nation can contain voters from multiple locations, state file ID becomes a unique identifier when it is combined with the registered state field. The first time a voter is imported, the profile's registered state field is standardized using the expected two-letter designation based on ISO 3166-2 standards. Registered state field is also standardized for use with a county file ID.
A couple of problems can occur when you try to update voter profiles via import and use state file ID or county file ID to match your import to existing records:
1. If the import includes anything other than a two-letter code for state, you will create duplicate profiles.
For example, updating profiles for voters who live in Alberta, Canada must include "AB" in the state field. If you list "Alberta" as the province, you will create duplicate profiles. This is true even if you imported the voters with "Alberta" listed in the state field during your initial import.
2. If you are matching on county file ID and the registered county field in the import is written differently than how it exists in your nation, you will create duplicate profiles.
For example, if a profile lists registered county as "County of Barrhead No. 11" and you import an update to the record with "Barrhead" listed in the registered county field, your second import will create a second profile. The original profile will not be updated. County names are never standardized, but they must be imported with the exact same spelling every time to ensure correct matching via county file ID.
These ID fields are listed on multiple pieces of documentation. By early next week, all of that documentation will be updated. Recently, our Frontline team has been helping several customers sort out duplicate profiles created by this quirk. This post is the first step in acknowledging the limitations of state file ID and county file ID. The documentation will be updated next week.
