Why would ISIS return a different name for a student than the class roster shows?

ISIS used to prioritize data in payroll record from QDB over student record from SRDB if a student works at UCLA and their payroll record shows a different name. After the Enterprise Directory rolled out in production in November 2006, ISIS switched its backend to ED which pulls a person’s name information based on a differenct logic. This ED name logic favors the name recorded in student system when different names are found in both student and payroll system for the same UID, if the person is a current student with UCLA. Therefore ISIS no longer returns the name in payroll system as long as the person is a current student. The only case that payroll name is returned instead of student record name is that the person is a current UCLA employee but not a current UCLA student.

Here’s the current name resolution logic implemented in ED:

a. If a person currently has student affiliation (meaning UID exists in V610), select the name in the order below no matter what other affiliation this person has:
1. SR0 name
2. SI0 name
3. PP0 name
4. UNX name

Note: If the name selected is found with APP_USAGE_STATUS <> ‘A’, an error message will be logged but the name still goes in ED.

b. Else, if a person currently has employee affiliation (meaning UID in payroll system with a emp_status<>S- ‘not seperated’), select the name in the order below:
1. PP0 name
2. SR0 name
3. SI0 name
4. UNX name

Note: If the name selected is found with APP_USAGE_STATUS <> ‘A’, an error message will be logged but the name still goes in ED.

c. Else, meaning a person does not have either student of employee affiliation, go with the same order of step a.

Exception: Students who have fullon ferpa restriction flag turned on in SIS/SRS are not recognized in the Enterprise Directory because their names in SIS/SRS are restricted for release. If they are UCLA employee at the same time, ED will populate their PP0 names instead of SR0/SI0 names.