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 type 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 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 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 behavior:
•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 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
Business applications, REST APIs
An objective is applied to source records created through business applications and REST APIs.
Note: When you update a record in a business application or send a PATCH API request, objectives aren't applied to patch records.
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
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. When you configure business applications as a trigger for an objective, you can select one of the following trigger conditions:
•On submission. An objective applies when a user submits a record.
•On section save and submission. An objective applies when a user applies changes to a section and when the user submits a record. An objective configured with this trigger condition allows users to view the results of the objective before they submit the record.
•On field focus change and submission. An objective applies when the focus on a field changes in a record and when the user submits the record. 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
Note: The On field focus change and submission trigger condition is for internal use only. Do not use it.
When a user applies 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 are triggered. The results of the rule associations from these objectives are displayed in the section. However, the results aren't saved to 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. If the record type is master records, objectives aren't triggered when a field focus changes or a user applies changes to a section.
Note: You can't trigger an objective when a user deletes a field group entry because deleting the entry removes the entire section. When a user applies changes to a section, the objective related to the updated fields runs all its rule associations except those that assign records to hierarchies.
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 a record is created or updated through REST APIs, MDM SaaS triggers the objective and all rule associations in the objective run. After the rule associations complete their 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.
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.
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:
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 following image shows the Reject records that fail validation setting 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 Reject records that fail validation setting is enabled by default. To allow records with validation errors to be created or submitted, disable the Reject records that fail validation setting.
If the error remediation property is enabled, the Reject records that fail validation setting is disabled by default.
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 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 setting overrides the error remediation property of business entities in business applications and REST APIs:
Trigger or trigger condition
Error remediation
Reject records that fail validation
Result
Business applications > On submission
Enabled
Disabled
Users can submit records with validation errors and the records display error messages.
Enabled
Enabled
Prevents users from submitting records with validation errors. The records display error messages.
Disabled
Disabled
Users can submit records with validation errors. However, the records don't display error messages.
Disabled
Enabled
Prevents users from submitting records with validation errors. The records display error messages.
Business applications > On section save and submission
Enabled
Disabled
Users can submit records with validation errors and the records display error messages.
Enabled
Enabled
Prevents users from submitting records with validation errors. The records display error messages.
Disabled
Disabled
If the fields within the section fail validation, prevents a user from saving a section. The record displays error messages.
Disabled
Enabled
If the fields within the section fail validation, prevents a user from saving a section. The record displays error messages.
REST APIs
Enabled
Disabled
API requests can create or update records with validation errors and the records display error messages.
Enabled
Enabled
Prevents API requests from creating or updating records with validation errors. The records display error messages.
Disabled
Disabled
API requests can create or update records with validation errors. However, the records don't display error messages.
Disabled
Enabled
Prevents API requests from creating or updating records with validation errors. The records display error messages.
Note: When you update a record in a business application or through a patch request, you can't reject the record if it fails validations.
For more information about the error remediation property of business entities, see Business entities properties.
