Multiple UIN Resolution Policy
The Multiple UIN Resolution policy, commonly referred to as First UIN Wins, summarizes the UIN Services policy in which if a person has been issued more than one UIN, the first, or original, UIN will be considered the official UIN for that person, even if subsequent UINs were utilized for a period. The subsequent UINs are deactivated and made to reference the first one.
UINs are assigned to more than just employees and students which can cause a person to be assigned more than one UIN as their affiliation with the A&M system changes. Often the “other” UINs aren’t detected until employee on-boarding or shortly after. Below is a real example of how this can happen.
- UIN #1 – In the past, when an employee enrolled in benefits, a UIN was assigned to their dependents, such as a spouse or child, for the purpose of managing benefits.
- UIN #2 – Years later, if that child applies to one of the A&M System universities as a prospective student, they are assigned a new UIN rather than being associated to their original UIN.
- UIN #3 – Shortly thereafter, the person accepts a job within the A&M system. However, their last name is different due to a legal name change such as marriage. During employee on-boarding, rather than associating this person with their original UIN, a new UIN is mistakenly created.
In this case, the ‘First UIN Wins’ rule is applied and UIN #1 becomes the official UIN. The other UINs are made inactive and reference the first/original UIN.
Why This Policy Exists
Identity management and data integrity is an important part of system security. Having a single and accurate well-managed user identity is necessary in enforcing this security.
The first UIN is typically referenced in multiple information resource systems including student information management, human resources, financial, and training. The UIN identifier must continue to be easily referenced back to the person. When a person is incorrectly assigned a new UIN, this relationship is lost or becomes obscured. This historical data must remain readily available.
Proper detection of an employee’s pre-existing UIN is the responsibility of UIN partners in the onboarding process and helps enforce system security by managing a centralized user identity system.
Limited Exceptions
Errors or mistakes in this process are not grounds for granting exceptions to the First UIN Wins rule.
As an example, the only known exception to this policy was in the case of a person who had a UIN created while applying for enrollment to a system member university. However, this person never enrolled so there were no other information systems referencing the UIN.
Years later, this person was hired as an employee, during which a new UIN was (improperly) created. The employee utilized this new UIN for two years, after which time it was noticed that an original UIN existed. Policy would dictate that this employee’s UIN be changed to reflect the original UIN, but an exception was granted to this policy because the original UIN was never actually used as a student.
Downstream Effects of Changing UIN
Workday is the system of record for each employee’s data, including the reference to the employee’s UIN. When an employee’s identity-related data such as UIN, name, or date of birth is changed in Workday, the new values are propagated into other enterprise systems like the UIN Master table, the Enterprise Data Warehouse, FAMIS, and other applications on the SSO menu. It will also impact integrated systems further downstream, including most system member’s Active Directories. These downstream systems are responsible for handling changes in UIN data.
UIN Manager provides a REST web service that publishes significant changes in UIN assignment. For more information email support@tamus.edu.