IAM in Service Catalog
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,
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.
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:
valididin the payload. The following attributes may be included:
studentidin the payload. No matching will be attempted otherwise. If
lnameare included, those must match the values for their respective fields on the record with the matching
studentidmatch but the other fields do not, the record will be created with a new identity.
studentid, the registry will attempt to match on
birthdate, if specified) first, then
birthdate, if specified)
ssn, then update
ssnlater, the registry will not attempt to match to another identity based on the new information.
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:
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: