Restrict People Import updates to only username

I see People Import uses Primary Email Address to match for updates. Since it is possible that incorrect email addresses can be entered in our HR and SIS systems. It is possible that a new user can match an existing user on preferred email address. Thereby updating the existing user with incorrect data. Is it possible to restrict matching on just username, which shouldn't have incorrect duplicates? I don't see where we can.

Thanks

Asked by Chuck Renninger on Mon 3/20/23 3:25 PM
Sign In to leave feedback or contribute an answer

Answer (1)

This answer has been marked as the accepted answer
Mark Sayers Mon 3/20/23 3:40 PM

Hello Chuck,

The people import process will always match on these fields, in this exact order:

  1. Username - If there already exists one or more people, regardless of active status, with the same TeamDynamix username as a row that is being imported, those records will be updated from the spreadsheet. This field will only be used for the purposes of matching. TeamDynamix username fields will not be updated as part of this process.
  2. Authentication Username - If there already exists one or more people, regardless of active status, with the same TeamDynamix authentication username as a row that is being imported, those records will be updated from the spreadsheet. This is the Auth Username specified for the user in the TDAdmin application. This field will only be used for the purposes of matching. TeamDynamix authentication username fields will not be updated as part of this process.
  3. Organizational ID - If there already exists one or more people, regardless of active status, with the same organizational ID as a row that is being imported, those records will be updated from the spreadsheet.
  4. Primary Email Address - If there already exists one or more people, regardless of active status, with the same primary email as a row that is being imported, those records will be updated from the spreadsheet.

There is no way to opt out of any of those fields as match fields, however if you have unique values for any one of the first three fields, you'll never have to worry about the system potentially performing duplication matching on the Primary Email Address field.

Additionally, ideally, the Primary Email Address value should *always* be the unique organization-created address for the user rather than some "preferred" address value, which can always be captured in the Alternate Email field.

Sincerely,
Mark Sayers
Sr Support Consultant, CS

No feedback