Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • Match Before Registry: ID Match is called before SOR data is initially presented to Registry, such that the SOR data already includes the Reference Identifier.
  • Match At Registry: ID Match is called by Registry upon receipt of a new SOR record. The SOR data does not include the Reference Identifier.

Match Before Registry

If the Reference Identifier will already be included in the OIS record, use the Identifier Pipeline Match Strategy. Records with the same Identifier of the specified type will automatically be linked together.

When Match Before Registry is used, the Match Reference Identifier will be available in the Org Identities associated with each backend, as well as the CO Person Record.

Match At Registry

The remainder of this document describes Match At Registry.

When Match At Registry is used with Organizational Identity Sources, the Match Reference Identifier will be available in the Org Identity Source Record (Org IdentityView Organizational Identity Source Record), but not in the Org Identity itself. It will also be available in the CO Person Record. When Match At Registry is used with Enrollment Flows, the Match Reference Identifier will be available in the Petition record and the CO Person Record.

System of Record Labels

The Match API operates with the concept of a System of Record Label, which is used to identify the calling system making the request to the ID Match server. System of Record Labels should be short and alphanumeric with no special characters, such as sis or hris.

System of Record Labels (v4.1.0 and later)

In Registry v4.1.0 and later, the System of Record labels are defined in the Organizational Identity Source or Enrollment Flow configuration. A unique System of Record label should be used for each configuration.

System of Record Labels (v4.0.x)

Registry supports two models for SOR Labels:

...

  • Server URL: The URL prefix for Match request. This should look something like https://match.university.edu/match/api/3/v1.
  • Username and Password: As configured.
  • SOR Label: As defined on the Match server, and in accordance with the model selected above. If the SOR per Source model model is chosen, then a Match Server will need to be defined for each SOR Label. (Registry v4.0.x only)

Match Attributes

After the Match Server is defined, Match Server Attributes can be added to the configuration to define which attributes Registry will send when making a match request. This configuration should align with the Match Server's attribute configuration.

...

  1. Configure the Enrollment Flow with Identity Matching set to External. Select the appropriate Match Server from the list provided.
  2. Make sure the Enrollment Attributes collected include CO Person attributes with the same configuration (including types, if appropriate) as the Match Server Attributes.
  3. Set Duplicate Enrollment Mode to an appropriate configuration.
  4. For Registry v4.1.0 and later, define the System of Record Label.

Handling Fuzzy Matches

If the match request is inconclusive, a list of potential candidates will be displayed as part of the Enrollment Flow. To link to an existing record, select the appropriate Reference Identifier. To create a new Reference Identifier, select "New".

...

Updating Match Attributes for Match Requests created by Enrollment Flows is not currently supported. (CO-2318)

...

Organizational Identity

...

Source Configuration

  1. For Registry v4.1.0 and later, define the System of Record Label.
  2. Attach a Pipeline to the OIS with a Match Strategy of External, and select the appropriate Match Server, defined above.

Handling Fuzzy Matches

If the match request is inconclusive, the Pipeline will fail. An administrator must login to the Match server and resolve the conflict. On the next attempt to process the Pipeline, the Reference ID will be obtained and processing will complete. Alternately, if the inconclusive result was caused by bad data in the SOR record, the record can be corrected and will be successfully processed on the next execution of the Pipeline.

...

Currently, records are never removed from the Match server, even after an expunge from Registry.

Match Resolution Notification Configuration

As of v4.1.0, Registry supports Match's Match Resolution Endpoint Notification Protocol via the Match Callback Core API.

When a Match Resolution Notification is received, Registry will attempt to map the SOR Label and SOR ID to an Organizational Identity Source using the System of Record Label configured on the OIS. If a matching configuration is found, a Sync Job will be queued to reprocess the SOR ID within the OIS, the Job will be processed the next time Job Shell processes the queue. (The record is not processed synchronously on receipt of the notification.)

To enable Match Resolution Notification processing:

  1. Create a new API User via ConfigurationAPI Users > (plus) Add API User.
    1. The API User should not be Privileged.
    2. After creating the API User, generate an API Key.
    3. (info) An existing API User can be reused if appropriate.
  2. Enable the Core API via ConfigurationCore APIs > (plus) Add Core API.
    1. Select the Match Callback API.
    2. Set the API User created in the previous step.

(warning) Match Resolution Notification does not currently support Match Requests generated by Enrollment Flows.