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.
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
When you configure triggers for an objective, you can configure the objective to run when a user creates records, updates records, or performs both actions.
For example, you are a data entry operator at NovaHealth Hospital. When you onboard a patient by creating their record, you want an objective to automatically populate fields such as record creation date and record status. Similarly, when you update the record with a new address, you want an objective to verify the address. To meet these requirements, you can configure an objective that runs only on new records. You can also configure an objective that runs only when an existing record is updated.
The following image shows the create and update actions enabled in the advanced settings of an objective:
Objective trigger modes
When you configure objectives, you can specify whether you want to run objectives automatically or on request.
You can configure an objective with one of the following modes:
Automatic
If you want objectives to run automatically when a record is created or updated, choose the trigger mode as automatic and configure the objectives with the triggers, such as business applications, ingress, and REST APIs.
On Request
If you want CLAIRE Copilot to run objectives, choose the on-request trigger mode and configure objectives with CLAIRE as the trigger. On-request objectives run when users request CLAIRE Copilot to enrich records using objectives.
Note:
You can configure on-request objectives only for master records.
Note:
Effective in the April 2026 release, the ability to configure the trigger modes is available for preview.
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.
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.
To run objectives when users ask CLAIRE Copilot to enrich records using objectives, use CLAIRE as a trigger for the objectives.
You can configure CLAIRE as a trigger only for on-request objectives.
When users ask CLAIRE Copilot to enrich records using objectives, the Copilot displays the on-request objectives. Users can select specific or all objectives to run using CLAIRE Copilot.
CLAIRE Copilot can't run the following types of objectives:
•Objectives that are configured to display enrichment data as recommendations
•Objectives that are configured to perform validation and cleansing
When you configure on-request objectives, don't use rule associations that use system fields as input fields. On-request objectives aren't triggered when system fields are updated.
Note:
Effective in the April 2026 release, the ability to configure CLAIRE as a trigger is available for preview.
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:
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.
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.
When you configure objectives that handle validations, you can choose to reject records that fail validations.
The following image shows the option to reject records that fail validation 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.
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.
Note:
If you enable the option to reject records that fail validation in an objective, include at least one rule association that has error severity set to Error. Records aren't rejected if rule associations have their error severity set to Information or Warning. When this option is enabled, if a rule association results in an exception, the record on which it ran is rejected. This behavior applies to all rule associations that perform validation, enrichment, or cleansing.
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 you 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.
Configuring objectives to run on empty fields
You can configure an objective to run when the input fields of all associated rule associations are empty.
When you enable the option to run an objective when input fields are empty, the objective runs in the following scenarios:
•When one or more of its input fields are updated
•When a field at the same level as its input fields is updated and all its input fields are empty
The following image shows the Advanced Settings dialog box with the option enabled to run an objective when input fields are empty:
Objectives with the setting enabled run when users create and update records. Enable this setting when you want to assign default values to empty fields or validate that required fields are not empty.
When you create an objective, the option is disabled by default. When this setting is disabled, the objective runs only when its input fields are updated with values during record creation and record update.
Configuring objectives to run on empty fields example
The following examples show how objectives behave when you enable or disable the option to run an objective on empty input fields:
•A product record has two root fields, such as Title and Brand Name. Title is the input field for the Complete Product Information objective, and Brand Name is the input field for the Verify Brand Details objective. A user creates a record, enters a value for the Title field, and leaves the Brand Name field empty. If you enable the setting, both objectives run because the Title field, which is at the same level as Brand Name, was updated. If you disable the setting, only the Complete Product Information objective runs, and the Verify Brand Details objective is skipped because its input field, Brand Name, is empty.
•A product record has an Address field group with two fields, such as City and State. City is the input field for the Validate Warehouse City objective, and State is the input field for the Validate Warehouse State objective. A user creates a record, enters a value for the State field, and leaves the City field empty. If you enable the setting, both objectives run because the State field, which is at the same level as City within the same address entry, was updated. If you disable the setting, only the Validate Warehouse State objective runs, and the Validate Warehouse City objective is skipped because its input field, City, is empty.
Guidelines for configuring objectives to run on empty fields
Consider the following guidelines when you configure an objective to run when its input fields are empty:
•Ensure that the data enhancement rule used in each rule association has a flat input field structure. You can't save an objective if any rule association uses a data enhancement rule with nested input field structure.
•Ensure that you don't map fields from more than one field group across all rule associations in the objective. For example, if one rule association maps fields from the Address field group and another maps fields from the Contact Details field group, you can't save the objective with those rule associations. Either disable the option to run on empty fields or configure all rule associations to map fields from the same field group.
•When you add multiple rule associations to an objective, ensure that all rule associations share at least one common field that triggers the objective. If a field from a field group is mapped to an input field of a plugin with a flat input structure, the rule association runs only when the user adds a value to the field group during record creation. For example, if the first rule association is triggered by the Address field group and the second is triggered by the Employment Details field group, the objective can't be saved. Review all rule associations in the objective and ensure that they share a common field that triggers the objective.
•Ensure that you don't map systems fields as input fields in any of the rule associations in objective. For example, if you map the Business ID system field as an input field, you can't save the objective.
•Ensure that the data enhancement rule in a rule association is configured to include only new or updated field group entries in the input payload. If the data enhancement rule is configured to include all field group entries in the payload when the rule association runs, you can't save the objective. For example, if the data enhancement rule is set to send all Address entries in the payload rather than only the new or updated ones, the objective can't be saved. In the data enhancement rule, enable the option to include only new or updated field group entries.
