You can determine when an objective is triggered and the types of records to which the objective is applied.
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 type of records to which an objective can be applied.
You can configure to apply an objective to master records, source records, or both. For example, you can apply an objective only to master records when they are created or updated in business applications.
When you specify record types for an objective, ensure that the compatible triggers are configured. For more information about triggers, see Objective triggers.
The following table lists the compatible triggers:
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. You can't apply an objective to master records created through ingress or file import.
Source records
REST APIs
An objective is applied to source records created through ingress, file import, or REST APIs.
When you select Source Records as the record type, 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 system are created or updated. For example, if you choose Salesforce as the source system for an objective, the objective will apply only to records with the Salesforce source system.
Note: After you import an objective group that you exported before the July 2025 release, if the input record type is changed to source records, change the record type to master records in the advanced settings of the objective
An objective trigger determines when to trigger an objective.
If you configure business applications as a trigger for an objective, the objective triggers when users submit records in business applications. You can also choose to trigger the objective when the field focus changes or when you apply changes in a section of a record. Objectives configured to trigger after a field focus change or section save allow users to preview the changes. The results of the rule associations in these objectives are saved only when a user submits the record. You can't trigger an objective when a user deletes a field group entry because the user deletes the section itself.
Note: When a user applies changes to a section, the rule associations that assign records to hierarchies don't run. If an existing objective applies when a section is saved and includes a rule association that assigns records to hierarchy, the rule association doesn't run. 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 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.
You can also enable REST APIs as a trigger for an objective. When records are created or updated through REST APIs, MDM SaaS triggers the objective and all rule associations in the objective run. 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.
You can configure an objective to allow one rule association to use the output from another rule association as input within the objective.
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.
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. This rule association validates the national drug code to check if the value in the field contains 11 characters. If the length is 9-10, the validation fails. 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. This rule association generates PCID by concatenating the value in the National Drug Code field with the country code.
3Generate MPID from PCID. This rule association generates MPID by removing the packaging code from the PCID value.
The following diagram shows how rule associations work without data dependency:
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:
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.
When you configure objectives that handle validations, you can choose to reject records that fail validations.
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.
By default, records with validation errors can be imported, created, or submitted.
Note: When you configure an objective to apply only to master records, you can't reject records with validation errors. To reject records with validation errors, you must configure the objective to apply to source records as well.
The following table describes how the setting overrides the error remediation property of business entities in business applications and REST APIs:
Setting
Enabled
Disabled
Reject records that fail validation
Rejects records that fail validation.
Allows import or submission of records that fail validation.
Error remediation
After a user submits a record with validation errors, the record displays error messages and the validation status.
After a user submits a record with validation errors, the record doesn't display error messages and the validation status.
For example, if the error remediation property is disabled and the Reject records that fail validation setting is enabled, records with validation errors are rejected in business applications without displaying error messages. For more information about the error remediation property of business entities, see Business entities propertiesBusiness entities properties.
