---
title: "Mappings, Matching and Event Governance"
slug: "mappings-matching-and-event-governance"
description: "Advanced mapping, matching and event governance in Studio for Rostering to and from Source and Target EdTech systems and applications. "
tags: ["Event Governance", "Field Mappings", "Studio", "Administrator", "Developer", "Rostering", "OneRoster"]
updated: 2023-06-03T17:58:26Z
published: 2023-06-03T17:58:26Z
canonical: "help.rapididentity.com/mappings-matching-and-event-governance"
---

> ## Documentation Index
> Fetch the complete documentation index at: https://help.rapididentity.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Mappings, Matching and Event Governance

## Studio Mappings, Matching and Event Governance

This article contains high-level background on Studio Record & Field Mappings in the context of matching and event governance.

### Mappings

Record mappings (along with their associated field mappings) tell Studio how to construct a target type record `B` given a source type record `A`.

### Matching

Studio matches the ( `A` , `B` ) pair based on equivalence of the special `recordKey` field. That is, the field mappings for the target field `recordKey` **govern matching**.

### Source Events

All field mappings are associated with one to three source events. These events include:

#### On Create (read: source record created)

- This is when `A` exists, but we can't find a matching record `B` in the target namespace/type.
  - That is, from Studio’s perspective, `A` has just been newly **created**.
- When this occurs, Studio will construct such a record `B` by applying the **On Create** field mappings to `A`.
  - Only fields governed by an **On Create** field mapping will actually be **created**.

#### On Delete (read: source record missing or deleted)

- This is when `B` exists, but we can't find a matching record `A` in the source namespace/type.
  - That is, from Studio’s perspective, `A` has been **deleted**.
- When this occurs, Studio will apply the **On Delete** field mappings to `B` to update it as needed.
  - Only fields governed by an **On Delete** field mapping will actually be subject to change. Studio will not modify any other fields but those governed by **On Delete** field mappings.
- If desired, we can delete `B` from the database. This is only done if there is a field mapping for the target field `recordStatus` that returns the value `delete`

          **Side Note:**

          

This is not specific to the **On Delete** field mappings; you could decide to delete records in any case based on logic that you implement. All you have to do is map this special value for `recordStatus`. That said, the most frequent use case would be with an **On Delete** field mapping.

#### On Update (read: source Record potentially updated)

- This is when both `A` and `B` exist (i.e. we found a match).
  - That is, from Studio’s perspective, `A` **may have been updated**.
    - We can’t know until we apply the update mappings to detect if any particular fields governed by the update mappings have actually changed → if any have, then we actually push the update out to `B`.
- When this occurs, Studio will apply the **On Update** field mappings with the data from `A` and `B` to modify `B`.
  - Only fields governed by an **On Update** field mapping will actually be subject to change. Studio will not modify any other fields but those governed by **On Update** field mappings.