Configure Data Quality > Orchestrating data enrichment and validations > Field mappings in rule associations
  

Field mappings in rule associations

When you create rule associations, you can map the input and output fields of the data enhancement rule to the business entity fields.
After a user updates one of the mapped input fields in a record and submits the record, the objective that the rule association is part of is triggered. The rule association runs, and the data that the data provider returns is applied to the mapped output fields. Based on the trigger settings in the objective, the objective is triggered when you ingress or import records, submit records in business applications, or create or update records through REST APIs.

Mapping field groups for data enrichment

When you map field groups in a rule association for data enrichment, consider the following restrictions:

Assigning static values to input and output fields

You can assign static values to input and output fields instead of mapping them to other fields.
In some cases, you might want to assign a static value to an input field instead of retrieving the value from a field in a record. Also, you might want to assign a static value as the output instead of retrieving from the data provider output fields. For example, if you want to translate the product description in a product record from English to French, you can assign English as the input value for the Language data provider field. You can also assign French as the output value for the Language business entity field.
MDM SaaS doesn't downgrade the trust scores of fields with static values. Only the trust scores of business entity fields that are mapped as input fields are downgraded. If you assign a static value to an input field and the field fails validation, the trust score of the input field isn't downgraded even if the plugin response contains a downgraded trust score for the input field. If the plugin response contains only system fields that failed validation or fields with static values, the rule association is marked with the Exception status.

Assigning static values to field groups

When you map input and output fields in a rule association, you can assign static values to the fields in a field group.
When you assign static values to the fields in a field group, you need to map at least one field from the source field group to a field in the target field group. You can’t assign static values to all fields in a field group. For example, you map the Address field group with the City and Country fields to the Address field group of the data provider. You can assign the static value US to the Country field, but you need to map the City field from the business entity field group to the City field of the data provider.
The following image shows invalid assignments of static values to fields in a field group:
The invalid field mappings show that the static values New York and US are assigned to both the City and Country fields in the target Address field group.
The following image shows a valid assignment of a static value to a field in a field group:
The valid field mappings show that the static value US is assigned to the Country field in the target Address field group. The mappings also show that the City field from the source Address field group is mapped to the City field in the target field group.
When you assign static values to the fields in a nested field group, map at least one field from the source nested field group to a field in the target nested field group.
The following image shows an invalid assignment of static values in nested field groups:
The invalid field mappings show that the static values hr@acme.com and Work are assigned to both the Electronic Address and Type fields in the nested Email field group. The mappings also show that 9000400001 and Work are assigned to the Phone Number and Type fields in the nested Phone field group.
The following image shows valid assignments of static values in nested field groups:
The valid field mappings show that the static value Work is assigned to the Type field in the nested Email field group, but the Electronic Address field is mapped to the Electronic Address source field. The mappings also show that the value Work is assigned to the Type field in the nested Phone field group, but the Phone Number field is mapped to the Phone Number source field.

Rules and guidelines for assigning static values

When you assign a static value to input and output fields, consider the following rules and guidelines:

Using system fields as input fields

You can use system fields, such as Business ID, Created By, and Last Updated By, as input fields for rule associations.
For example, you can prevent a user from updating a field in a record based on the created date of the record.
If an objective is configured to trigger when the field focus changes or a user applies changes to a section during record creation, you can use only the following system fields as input fields:
You can use all system fields as input fields for record update scenarios. If you use only the system fields as input fields in a rule association that validates records, records don't display error messages when they fail validation.
When you use system fields as input fields in a rule association for validation and cleansing, use at least one business entity field as an input field. Rule associations for validation and cleansing aren’t triggered based on only system field changes. However, when you configure a rule association for enrichment, you can choose to use only system fields as input fields without using any business entity fields.
When an objective is triggered on a master record, all mapped system fields of all source records associated with that master record are included in the payload sent to a plugin. For example, if you map the source system field in a rule association, the source system fields from all source records are included in the payload when the rule association runs on a master record. However, if an objective runs on a source record, only the mapped system fields of that source record are included in the payload.
MDM SaaS doesn't downgrade the trust scores of system fields. Only the trust scores of business entity fields mapped as input fields are downgraded. If you map system fields as input fields and their values fail validation, the trust scores of the system fields aren't downgraded even if the plugin response contains downgraded trust scores for the system fields. If the plugin response contains only system fields that failed validation or fields with static values, the rule association is marked with the Exception status.

Guidelines for mapping fields

When you configure rule associations for data enrichment in Business 360 Console, consider the following guidelines to map input and output fields:

Compatible data types between business entity fields and data provider fields

When you map input and output fields in a rule association, map compatible fields.

How MDM SaaS handles plugins with flat input payloads

When you map both root fields and field groups or nested field groups in a rule association that requires flat input payload, MDM SaaS flattens the innermost mapped field group. That field group acts as the trigger for the rule associaiton when users create or update records in a business application.
The rule association runs only if users add values to at least one of the mapped fields of that innermost field group. If they add values to only the root fields and submit a record, the rule association doesn't run.
For example, consider that the Address Verification plugin from Data Quality needs the First Name, Locality 1, Locality 2, Postal Code, and Country as input. Even though Locality 1, Locality 2, Postal Code, and Country are address details, the input fields don't belong to a field group. If you map the First Name field and the fields of the Address field group to these input fields, MDM SaaS flattens the structure to match the format the plugin requires.
The following image shows a sample mapping of Person business entity fields to the input fields of a plugin:
In the sample mapping, the fields from the Address field group are required input fields for the rule association to run. When a user creates a record with just the first name without adding values to any of the mapped fields of the Address field group, the rule association doesn't run.
This happens because the field group is flattened and a flat input is sent to the plugin when a user creates a record. Root fields are repeated in each of the field group entries to preserve the relationship between root fields and field group entries in a flattened structure. Consider that the user enters two addresses for a person called John.
The following JSON represents a sample flattened input:
[
{
"First Name": "John",
"Locality 1": "123 Main Street",
"Locality 2": "Apt 4B",
"Postal Code": "10001",
"Country": "United States"
},
{
"First Name": "John",
"Locality 1": "456 Oak Avenue",
"Locality 2": "Suite 100",
"Postal Code": "90210",
"Country": "United States"
}
]
In the sample payload, the first name is repeated in both entries. The Address field group is considered a required field for the rule association to run. If fields from a nested field group are mapped as input fields, the nested field group is considered the required field for the rule association to run.
The following image shows a sample field mapping with a nested field group:
In the example, the Phone field group becomes a required field. When a user creates a record without adding a phone number, the rule association doesn't run.
Most plugins require MDM SaaS to send a flat input payload. When a rule association runs, MDM SaaS dynamically determines whether a plugin requires a flat structure and flattens the mapped business entity fields to match the expected format of the plugin.
Based on how you design the input and output payloads, the following plugins can have a nested or flat payload structure:
All other plugins in Enrichment and Validation Orchestrator have a flat input payload structure by default.