IDM’s use of PPS Data
User identification
Uniquely identifying individuals for purposes of creating accounts. Use Biodemo data to match against people who exist in other source systems (Manual accounts, Student System, Faculty system) to avoid creation of duplicate accounts.
Identification of Current Employees
Based on PPS Status and PPS Appointment data, identify individuals as “Active” or “Leave” employees. Some “fuzzy” logic is used to deal with status “I” employees.
Identification of Employment Status Information
To the extent feasible, provide information about a person’s employment status. This includes information such as Home Department, Department (from Level 4 Org), Appointment Type (Staff, Academic, Student), Senate Status and a (calculated) Appointment Status. Downstream systems generally want to use this information to determine eligibility for services and for directory information.
Validation of Employee Identity (partially implemented)
IDM systems are required to do “Identity Vetting” of certain types of account holders. This involves attesting to three main verification checks:
(1) That the identity belongs to an actual person (i.e., the individual did not provide a fake identity)
(2) that the individual is the identified person (e.g., a driver’s license was checked) and
(3) the person who gets the account/CruzID is the same person whose identity was verified
Our strategy for validating account holders relies strongly on trusting that the first two steps are followed as part of the HR process, and that there is some formal handoff between HR and the Support Center so that when the account is delivered to the individual, the Support Center has a way to know they are talking to the same person that HR hired.
Concerns and gaps with current PPS data
Tracking of Job-Related system access (cancelled, but still desired)
As originally designed, the IDM system was intended to allow certain kinds of system access to be tied to an employee’s job. E.g., a staff member would be granted Student System access as long as the individual held the same job. Because IDM only receives appointment information from PPS, and appointments change for many reasons unrelated to job title/job duty changes, this model was scrapped, but if the new system were able to provide information about “jobs” rather than “appointments”, we would consider returning to this model.
Org chart, Supervisor and other employee-info based data
For purposes of populating campus directories and building automated approval and access systems, having authoritative data about an employees business-department affiliations and supervisor<->supervisee relationships would be very helpful. Our PPS appointment information (which is based on distribution codes) is too inexact to use to populate departmental directory listings or to control access to department-specific information.
Process/timing issues
Because IDM accounts are created in response to data entry in PPS, any delay between an employee starting work and being entered into PPS creates a delay in granting the user’s CruzID and IT access. Given current HR processes, this means that in general accounts are not created for new employees until several days after they arrive on campus. Most offices end up requesting accounts through manual processes to speed account delivery, resulting in more work and some inaccuracies in account creation (inaccuracies that can lead to duplicate account creation).
Data that IDM gathers about employees separate from HR
Currently IDM allows Staff and Faculty to manually enter their own Department and Division affiliations, preferred (vs. legal) name and other directory information that is used to populate online directories. See campusdirectory.ucsc.edu for full listing. In the original IDM design, it was hoped that organizational data, preferred name information and other employee bio demo data would come from the HR system.