How multiple UINs for a person come about:
Unfortunately, it often happens that a single individual is assigned multiple UINs over the course of time as additional services are provisioned, rather than that individual being recognized as previously having a UIN. Here is an not-so-extreme example:
- In the past, when an an A&M System employee had a child, a side effect of configuring health care benefits for that child was that a new UIN was created and assigned (UIN #1).
- Years later, that child chooses to apply to one of the many A&M System universities; during the application process this person is wrongly assigned a brand-new UIN rather than being associated to the original UIN. Thus we have UIN #2.
- Some time later, due to marriage or legal name change, this person’s last name changes, and then this person happens to accept a job within the A&M System. During employee on-boarding, rather than associating this person with their original UIN, a new UIN is mistakenly created. (UIN #3).
When these situations are detected (most often during employee on-boarding or shortly after), the resolution process utilizes the ‘First UIN Wins’ rule: Within the SSO environment, UIN #2 and #3 are both configured as Unused UIN? = Yes (as seen in UIN Search) and the Good UIN field containing the value of the original UIN (UIN #1 in our example).
So what happens in the systems that are referencing the incorrect UINs?
Within the SSO ‘native’ applications, such as UIN Search, UIN Manager, TrainTraq, HRConnect and others, this ‘UIN Referencing’ mechanism works correctly.
However, there are many independent, external services that also utilize UINs, such as Banner school systems, the HR system Workday, and other, smaller applications that utilize SSO for authentication but are not tightly integrated. These applications have varying degrees of support for ‘UIN Referencing’. In general, the larger applications such as Workday and Banner either automatically reconcile these changes or have personnel that perform manual reconciliation.