Skip to content Skip to site navigation

Affiliations

Affiliation information in the Person Registry is a deeply structured set of information all relating to a specific relationship one has with the University. It consists of data that describes the affiliation itself as well as instances of other data types -- phones, addresses, etc. -- that can be associated with an individual affiliation. This document discusses only the descriptive affiliation data.

Parts of an Affiliation

Each affiliation in the Registry is stored as a single row in the affiliation table of the Person Registry database. An affiliation consists of these parts:

What Required? Schema xml
Organization yes organization_cd <affiliation organization="..."> attribute
Type of affiliation yes type_cd <affiliation type="..."> attribute, in form "affiliation:qualifier"
Affiliation qualifier no code
Affiliation text yes (XML only) n/a <affiliation>#PCDATA
Effective date no effective_date <affiliation effective="..."> attribute
Until date no until_date <affiliation until="..."> attribute
Description no description <affiliation>
    <description>#PCDATA
Department regid no department_regid <affiliation>
    <department>
        <organization regid="...">
Department code no department_cd If Stanford org:

<affiliation>
    <department>
        <organization ... adminid="..." acadid="...">

If non-Stanford org (e.g., hospital):

<affiliation>
    <department code="...">

Department name no department_name <affiliation>
    <department>#PCDATA

Organization

Coded value to indicate the larger organization to which an affiliation belongs. Currently the Person Registry supports just two organizations:

  • stanford -- Stanford University as a whole, including all schools and divisions (including SLAC).
  • sumc -- Stanford University Medical Center, including the Stanford Hospital and Clinics plus the Lucille Packard Children's Hospital.

Type of Affiliation and Qualifier

Coded value indicating a specific relationship to the University, as Faculty, Staff, Student or Affiliate, with optional qualifier to indicate subsets of those populations. See Affiliations Types and Qualifiers.

Affiliation/qualifier text

Expanded, display form of the coded affiliation and qualifier, from the affiliation_code metadata table.

Effective date

The date an affiliation became effective. This is data about the affiliation itself and should indicate the date the source system has for the start of an affiliation. It is not an effective-dating mechanism to control the affiliation within the Person Registry.

Until date

The date an affiliation ends in terms meaningful to the source. This is data about the affiliation itself, not an end-dating mechanism to control the affiliation within the Person Registry. Faculty and staff are typically continuing employment until terminated. PeopleSoft/HR does not send until_dates for any employees, including fixed term. For active students this indicates the end date of their current enrollment/registration; for recent students it indicates the end of the 5-year definition for "recent" student privileges.

Department regid

The organizational regid, from the Organization Registry, for the department or other organizational unit to which the affiliation belongs. Occurs only for Stanford University (not SUMC) organizations. Incoming document should declare an explicit adminid or acadid in the <organization> sub-element in <affiliation>. The lookup to the Organization Registry should be for identifiers of type adminid, acadid or xacadid (prior acadid assignment) respectively to find the corresponding organization's regid.

Department code

If a department is identified by a coded value on input, that value is remembered here, whether it resolves to an Organization Registry reference or not.

Department Name

The department or organizational name. technically it is optional if the source specifies a known organization via a regid or code, since we want to use the organization registry as to determine any current organization name. A stored organizational name is only functionally required when the source (e.g., Hospital) provides a local (to the source) code and name not known to the Registry. In practice however we store a department name in the affiliation row for all affiliation, primarily for DataAdmin or other data-analysis convenience.

Description

Descriptive text to supplement or summarize the affiliation. For faculty and staff this contains the person's job title -- their preferred title if present else JCC job title:

  • Preferred title in affiliation_extension, type_cd='jobtitle'
  • JCC (job class code) derived title is in affiliation_extension, type_cd='code'

For students it's a value derived from their career/plan information:

Undergraduate   --   if <affdata type="career"> is UG
Graduate   --   if <affdata type="career"> is GR
Graduate, Business   --   if <affdata type="career"> is GSB
Graduate, Law   --   if <affdata type="career"> is LAW
Graduate, Medicine   --   if <affdata type="career"> is MED

Affiliation extension (affdata)

Information from different sources about affiliations can vary a great deal. Affiliation extensions or affdata are a data construct that supports source-system-defined extra pieces of information. Like much Registry data, this information has "types", but here the source system establishes the types it wants to send along with an affiliation. The student system adds information about a student's academic "career, program and plan", while faculty and staff get added job information like JCC (Job Class Code).

What Required? Schema xml
Type of data yes type_cd <affiliation>
    <affdata type="...">
Code no value <affiliation>
    <affdata code="...">
Value yes value_text <affiliation>
    <affdata>#PCDATA

Type of data

Source-specific affiliation extensions. Though mostly defined solely through the external system definitions, specific affdata can be given rules that enhance their value. For instance, for faculty and staff, affdata of type=jobtitle is used to indicate a preferred job title and is used by Person closeout in calculating the best description.

Code

Coded value, if any.

Value

Full data value.

Examples:
type code value
career UG Undergraduate
job 1125 Emeritus Faculty

Data integration rules

Affiliations from the source to the registry

Affiliation types, qualifiers, descriptive data and affdata are all externally sourced information from contributors and are determined on a client by client basis.

Affiliations in the registry outbound Person XML document

Affiliations in the Person registry are contained in the person level <affiliation> element in the document. Starting with person 1.1, all affiliation extensions are relayed as <affdata> elements.

Events

Registry/Directory synchronization events

The Person Registry posts an registry_person:reconcile for any change in affiliation data.

Infrastructure person events

The Person Slog process that maintains the Person data in the Directory posts the following events after updating the directory:

Directory attribute event (domain:topic) parm1
o person:affiliation [null]
ou person:affiliation [null]
suDisplayAffiliation person:affiliation [null]
suPrimaryOrganizationID person:affiliation [null]
suStanfordEnddate person:affiliation [null]
suAffiliation person:affiliation [null]
Last modified September 9, 2020