Skip to end of metadata
Go to start of metadata

Overview

An identity can be composed of several sets of identity data.  For example, the same person could be a student, employee, and alumna.  This person would have a single identity, but multiple source records would be associated with it.  To use the technical terms from the IRWS API, this person would be described by a single regid, but would have source records of type, uwhr, sdb, and advance.  An identity can only be associated with one source record of a particular type.  The Auto Match function helps to associate new source records with existing identities, if appropriate.  

Matching and Prevention of Redundant Identities

The identity registration service (IRS–not IRWS–this functionality is in the registry itself and not part of the API) tries to match new source records to an existing identity before creating a new identity.  This helps prevent confusion if an employee becomes a student, or vice versa.  If a new record were created for each source records, the same "person" would exist more than once in the registry.  The flowchart below describes the matching logic in detail, but here are some notes on the process:

  • The process described here only applies to PUT operations for source records in the Person resource
  • For non-UWHR source records, you must include validid in the payload.  The following attributes may be included:
    • lname
    • ssn
    • studentid
    • priorid
    • birthdate
  • For matching to be attempted, you must include at least ssn or studentid in the payload.  No matching will be attempted otherwise.  If birthdate and/or lname are included, those must match the values for their respective fields on the record with the matching ssn or studentid.  If ssn or studentid match but the other fields do not, the record will be created with a new identity.  
  • If your payload includes both ssn and studentid, the registry will attempt to match on ssn (and lname and birthdate, if specified) first, then studentid (and lname and birthdate, if specified)
  • Matching is only attempted when a record is first created.  For example, if you create a new record without ssn, then update ssn later, the registry will not attempt to match to another identity based on the new information.
  • Matching on lname is not generally affected by capitalization, spaces, or punctuation in names.  

Example 1:  You submit a payload with ssn, lname, and birthdate.  ssn and lname match an existing identity, but you transposed two letters in birthdate.  The registry will create a new identity for this record since birthdate did not match.  

Example 2:  You submit a payload with only ssn.  ssn matches an existing identity.  The registry will create this record and associate it with the existing identity that was matched.  




For UWHR source records only, validid is not required in the payload. You can request that the registry generate a UWHR validid by doing all of the following:

  • Specifying an asterisk ( * ) instead of validid in the URL
  • Not including the validid key in the payload. 

On the flowchart below, a starting point for this special process is shown, but the validid generation and assignment steps are not shown.

If the payload does not match any existing identities, or if the payload matches a single non-employee identity (i.e. not associated with any UWHR records), then the registry will will assign the record the next available UWHR validid (Employee ID Number) and add the record (to a new identity, or to an existing identity, respectively).

The record is not created, and a 409 error is returned, under the following conditions:

  • The payload matches more than one existing identity (this should be rare)
  • The payload matches an identity that is already associated with a UWHR record

 

 

 

 

 

  • No labels