Onboarding Scenario 1: HR Hires Student
Graduate student is hired as a part-time instructor. Was previously a part-time library employee (but no longer active).
Integration Methodology 1: Registry Up Front
- SOR calls ID Match service
Match::SORHasNewPerson
, returns Identifier- Note that if the HR system failed to recognize the previous role (thus trying to add new person instead of add new role), the Match service could return the existing SORID back to the SOR. This should probably be called out as part of the protocol.
- SOR calls
Write::SorPersonAdded
, maybe returns attributes - Attributes passed from HR to Registry:
- Name (Legal, Preferred, FKA, Professional/Author)
- Identifiers: SSN, SORID, RoleID, NetID
- Affiliation (eduPersonAffiliation through fine-grained)
- Employee Types: Contractor, Professional, Researcher, etc
- Email Address (eg: vanity domains, forwarding, etc) (might not be asserted by an HRMS, except maybe for an applicant)
- Address (Office, Preferred, Home)
- Phone (Office, Fax, Mobile, Home)
- Title/Position (Official, Preferred) (String or Code)
- Division/Department (String or Code)
- Employee Status (Active, Terminated, Deceased, Leave of Absence, Military Leave, Emeritus, Retired, Sabbatical)
- Percent Time
- Valid From/Valid Through/Hire Date/Termination Date
- Citizenship/Visa Status
- Date of Birth
- Ethnicity
- Gender
- Marital Status
- Directory Release
- Campus/Location ID (Assigned vs Actual Location)
- Person Linkage (Reporting Relationship/Sponsor)
Integration Methodology 2: Registry Later
- SOR calls
Write::SorPersonRoleAdded
, returns Identifier and maybe other attributes
Integration Methodology 3: Direct Integration
- SOR calls ID Match service
Match::SORHasNewPerson
, returns Identifier - SOR calls
Write::SorPersonAdded
, maybe returns attributes - SOR calls
Read::*
for operational tasks
Integration Methodology 4: Master Data Management
- SOR calls MDM service
- MDM services calls
Write::PersonUpdated
- SOR calls
Write::SorPersonRoleAdded
Attribute Change Scenario 1: Official Name Change
- SOR is authoritative (with or with MDM)
- SOR is not authoritative (registry calculates official name)
TODO: Expand above
TODO: Student Attributes
- Residence Hall (String or Code, for SIS)
- School/Campus (for student data)
- Class Year
- Graduation Date
TODO: What about non-person entities? Tracking vendors, test records, etc?