Configure Data Quality > Orchestrating data enrichment and validations > Advanced objective settings

Advanced objective settings

You can configure when an objective is triggered and the types of records to which it applies.

You can configure to reject records that fail validations. You can also enable data dependency between rule associations.

Specifying record types for an objective

You can specify the types of records to which an objective can be applied.

You can select master records, source records, or both as input record types for an objective. For example, you can apply an objective only to master records when you create or update them in business applications.

When you set source records as the input record type for an objective, the objective is triggered whenever source and patch records are created or updated. Also, you can refine the condition further by specifying one or more source systems. When you specify a source system, the objective is triggered when source records with the specified source systems are created or updated. For example, if you choose Salesforce as the source system for an objective, the objective applies only to records with the Salesforce source system.

When you select both master and source records as input record types for an objective, consider the following behaviors:

•Based on the source systems that you specify, the rule associations in the objective run on source records from the specified source systems. The results of the rule associations are applied to the source records. Based on the survivorship configuration, the changes might survive to the master records.
•After the master record is created or updated, the rule associations run on the master record again. The results of the rule associations are then applied to the master record.

When you specify record types for an objective, ensure that the compatible triggers are configured. For more information about triggers, see Configuring business applications as an objective trigger.

The following table describes the compatible triggers for input record types:

Record Type	Triggers	Description
Master records	Business applications, REST APIs	An objective is applied to master records that are created through business applications and REST APIs. The objective isn't applied to master records created through ingress or file import. Note: When you restore a deleted master record, objectives configured for master records are triggered and applied to the master record.
Source records	Ingress, Business applications, REST APIs	An objective is applied to source records created or updated through business applications, ingress, file import, and REST APIs.

Note: After you import an objective group that you exported before the July 2025 release, if the input record type is set to source records, you can change the record type to master records in the advanced settings of the objective

For more information about configuring the record types, see Step 2. Adding objectives to an objective group.

Configuring business applications as an objective trigger

To apply an objective when users create or update a record in business applications, you can configure business applications as triggers for the objective.

When you configure business applications as a trigger for an objective, you can select one of the following trigger conditions:

•On submission. The objective applies when a user submits a record.
•On section save and submission. The objective is applied when a user applies changes to a section or submits a record. This condition allows users to view the results of the objective before they submit records. Objectives for master records aren't triggered by this condition. If an objective configured with this trigger condition includes a rule association that adds records to hierarchies, you can't save the objective.
•On field focus change and submission. The objective is applied when the focus on a field changes in a record and when users submit the record. Objectives for master records aren't triggered by this condition.

Rule associations configured with the following plugins don't run when the field focus changes in a record:

- Application Integration-based Cleansing
- Application Integration-based Enrichment
- Application Integration-based Validation

If an objective configured with this trigger condition includes a rule association that adds records to hierarchies, you can't save the objective.

When users apply changes to a section in a record or the focus changes on a field in a record, the objectives configured with the On section save and submission or On field focus change and submission condition is triggered. The results of the rule associations from these objectives are displayed in the section. However, the results aren't saved in the record. When the user submits the record, the objectives are triggered again, and the results of the rule associations are applied to the record before it's saved.

Only the objectives configured for source records are triggered when a field focus changes or a user applies changes to a section. Objectives aren't triggered for master records when a field focus changes or users apply changes to a section.

Note: Objectives aren't triggered when users delete a field group entry because deleting the entry removes the entire section.

If you configure an objective to reject records with validation errors, users can't submit records that fail validation. For more information about rejecting records that fail validation, see Rejecting records with validation errors.

For more information about configuring these triggers, see Step 2. Adding objectives to an objective group

Configuring ingress as an objective trigger

You can configure an objective to be triggered when you import or ingress source records.

You can't trigger an objective for master records during ingress or file import.

Rule associations in an objective run during the Load step when you ingress or import files. If you configure the objective to reject records with validation errors, records that fail validation are rejected. To identify rejected records, you can download the Rejected Records report from the Errors section in the Load step of the job. You can also use the report to identify rule associations that fail with the Exception status.

Note: Rule associations that use the following plugins don't run during ingress or import of records:

•Application Integration-based Cleansing
•Application Integration-based Enrichment
•Application Integration-based Validation

Configuring REST APIs as an objective trigger

To trigger an objective when records are created or updated through REST APIs, you can configure REST APIs as an objective trigger.

When a record is created or updated through REST APIs, MDM SaaS triggers the objective and all rule associations in the objective run. The results are applied to the record before it is saved. The API waits until the record is saved before returning a response. If you configure the objective to reject records with validation errors, records that fail validation aren't created or updated, and the API returns information about the validation error.

If you configure an objective to reject records with validation errors, records that fail validation can't be created or updated. For more information about rejecting records that fail validation, see Rejecting records with validation errors.

For more information about configuring these triggers, see Step 2. Adding objectives to an objective group

Data dependency between rule associations

You can configure an objective to allow a rule association to use the output of another rule association as its input.

Rule associations within an objective run sequentially. By default, a rule association can't use the output of another rule association as input. You can override this behavior by enabling data dependency between rule associations within the same objective.

Note: If one of the rule associations fails with the Exception status, the subsequent rule associations in the objective don't run.

For example, consider that you work for a pharmaceutical company. To comply with regulations in the US market, you already use a unique National Drug Code (NDC) with every product. To comply with regulations in the European markets, you want to generate Medicinal Product Package Identifier (PCID) and Medicinal Product Identifier (MPID) codes from the National Drug Code.

To meet this validation and enrichment requirement, configure the following rule associations in an objective:

1Validate and Cleanse NDC. Validates the national drug code to check if the value in the field contains 11 characters. If the length is 9-10, the rule association adds zeros to the input value and returns the cleansed value. If the length is below 9, the validation fails, and the rule association returns validation results without any cleansed data.
2Generate PCID from NDC. Generates PCID by concatenating the value in the National Drug Code field with the country code.
3Generate MPID from PCID. Generates MPID by removing the packaging code from the PCID value.

The following diagram shows how rule associations work without data dependency:

The rule association execution flow shows that the PCID field has US-12-3456-090 as the output value, which is incorrect. The flow also shows that the MPID field isn't updated with an output value.

MDM SaaS saves the results only after all rule associations complete their run. In this sample scenario, the MPID field remains blank because the Generate MPID from PCID rule association didn't get the result of Generate PCID from NDC rule association.

When a user enters 12-3456-090 in the National Drug Code field and submits the record, the Validate and Cleanse NDC rule association standardizes the value to 0012-3456-090. However, this value isn't saved to the record until all rule associations complete their run. As a result, when the Generate PCID from NDC rule association runs, the National Drug Code field still contains the value 12-3456-090. The rule association adds the country code to that value and generates the value US-12-3456-090 for the PCID field.

The following diagram shows how the rule associations work with data dependency:

The rule association execution flow shows that the Validate and Cleanse NDC rule association uses the output of the Generate PCID from NDC rule association as input.

When a user enters 12-3456-090 in the National Drug Code field and submits the record, the Validate and Cleanse NDC rule association standardizes the value to 0012-3456-090. The Generate PCID from NDC rule association gets the output of the previous rule association as input. The rule association adds the country code and generates US-0012-3456-090, which includes country code plus the 11-digit drug code. The Generate MPID from PCID rule association gets the output US-0012-3456-090 from the previous rule association as input. It removes the packaging code from the PCID value to produce the MPID value US-0012-3456.

Note: If data dependency between rule associations is enabled for an objective, disabled rule associations in the objective don't run when the objective is triggered. If an objective includes a disabled rule association, the subsequent rule association might not receive an input value from the disabled rule association.

For more information about enabling the data dependency between rule associations, see Step 2. Adding objectives to an objective group.

Rejecting records with validation errors

When you configure objectives that handle validations, you can choose to reject records that fail validations.

The following image shows the Reject records that fail validation setting for the Business applications and REST APIs triggers:

The Advanced Settings dialog box shows the Triggers tab with the Prevent submission of records that fail validation and Reject records that fail validation options selected for the Business Applications and REST APIs triggers.

Note: This setting is called Prevent submission of records that fail validation for the Business Applications trigger.

If the error remediation property of a business entity is disabled, the option to reject records that fail validation is enabled by default. To allow records with validation errors to be created or submitted, disable the option to reject records that fail validation. If the error remediation property is enabled, the option to reject records that fail validation is disabled by default.

You can't reject master records that fail validation. If you enable the option to reject master records that fail validation, you can't save the objectives. To reject records with validation errors, configure objectives for source records or both master and source records.

Note: If you created an objective for master records with the option to reject records that fail validation before October 2025, you can't save changes after you edit the objective. You need to either disable the option to reject records that fail validation or configure the objective for master and source records.

The Reject records that fail validation setting works only when you specify error as the error severity in the rule association that performs validation. If you specify information or warning as the severity, records that fail validation aren't rejected.

The following table describes how the Reject records that fail validation setting works with the On submission trigger condition:

Reject records that fail validation	Error remediation	Result
Disabled	Enabled	Users can submit records with validation errors and the records display error messages after users submit records.
Enabled	Enabled	Users can't submit records with validation errors. The records display error messages after users try to submit records.
Disabled	Disabled	Users can submit records with validation errors. However, the records don't display error messages after users submit records. Note: When use the On Submission trigger condition, if you disable both the option to reject records and the error remediation property, users can't see error messages. So, avoid disabling both properties.
Enabled	Disabled	Users can't submit records with validation errors. The records display error messages after users try to submit records.

The following table describes how the Reject records that fail validation setting works with the On section save and submission condition:

Reject records that fail validation	Error remediation	Result
Disabled	Enabled	Users can submit records with validation errors. The records display error messages after users save the section and after users submit the records.
Enabled	Enabled	When the fields within a section fail validation, users can't save the section. The records display error messages after users try to save the section.
Disabled	Disabled	When the fields within a section fail validation, users can save the section and submit the record. The record displays error messages after users save the section. The record doesn't display error messages after users submit the records.
Enabled	Disabled	When the fields within a section fail validation, users can't save the section. The records display error messages after users try to save the section.

The following table describes how the Reject records that fail validation setting works with the On field focus change and submission trigger condition:

Reject records that fail validation	Error remediation	Result
Disabled	Enabled	Users can submit records with validation errors. The records display error messages after the field focus changes and after users submit the records.
Enabled	Enabled	When a field fails validation, users can't save the section. The records display an error message after field focus changes.
Disabled	Disabled	When a field fails validation, users can save the section and submit the record. The record displays an error message after the field focus changes. The record doesn't display error messages after users submit the records.
Enabled	Disabled	When a field fails validation, users can't save the section. The records display error messages after the field focus changes.

For more information about the error remediation property of business entities, see Business entities properties.