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

  1. SOR calls ID Match service Match::SORHasNewPerson, returns Identifier
    1. 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.
  2. SOR calls Write::SorPersonAdded, maybe returns attributes
  3. Attributes passed from HR to Registry:
    1. Name (Legal, Preferred, FKA, Professional/Author)
    2. Identifiers: SSN, SORID, RoleID, NetID
    3. Affiliation (eduPersonAffiliation through fine-grained)
      1. Employee Types: Contractor, Professional, Researcher, etc
    4. Email Address (eg: vanity domains, forwarding, etc) (might not be asserted by an HRMS, except maybe for an applicant)
    5. Address (Office, Preferred, Home)
    6. Phone (Office, Fax, Mobile, Home)
    7. Title/Position (Official, Preferred) (String or Code)
    8. Division/Department (String or Code)
    9. Employee Status (Active, Terminated, Deceased, Leave of Absence, Military Leave, Emeritus, Retired, Sabbatical)
    10. Percent Time
    11. Valid From/Valid Through/Hire Date/Termination Date
    12. Citizenship/Visa Status
    13. Date of Birth
    14. Ethnicity
    15. Gender
    16. Marital Status
    17. Directory Release
    18. Campus/Location ID (Assigned vs Actual Location)
    19. Person Linkage (Reporting Relationship/Sponsor)

Integration Methodology 2: Registry Later

  1. SOR calls Write::SorPersonRoleAdded, returns Identifier and maybe other attributes

Integration Methodology 3: Direct Integration

  1. SOR calls ID Match service Match::SORHasNewPerson, returns Identifier
  2. SOR calls Write::SorPersonAdded, maybe returns attributes
  3. SOR calls Read::* for operational tasks

Integration Methodology 4: Master Data Management

  1. SOR calls MDM service
  2. MDM services calls Write::PersonUpdated
  3. SOR calls Write::SorPersonRoleAdded

Attribute Change Scenario 1: Official Name Change

  1. SOR is authoritative (with or with MDM)
  2. SOR is not authoritative (registry calculates official name)

TODO: Expand above

TODO: Student Attributes

  1. Residence Hall (String or Code, for SIS)
  2. School/Campus (for student data)
  3. Class Year
  4. Graduation Date

TODO: What about non-person entities? Tracking vendors, test records, etc?

  • No labels