New features and enhancements

The data enrichment framework is now called Enrichment and Validation Orchestrator. You can use this framework to validate, transform, enrich, and cleanse data through rule associations.

You can add multiple rule associations to an objective and run them sequentially. You can configure when to trigger an objective and determine the types of records to which you want to apply the objective.

The following image shows an objective and its configuration:

You can also determine whether a rule association can use the output from another rule association as its input within an objective. Optionally, you can now assign static values to input and output fields in rule associations.

When you configure validations, you can choose to reject records that fail validations. This setting overrides the error remediation property of business entities.

For more information about enrichment and validation configuration, see Orchestrating data enrichment and validations.

When you create or update records by using REST APIs, you can now add or update dynamic field definitions and dynamic field values.

For more information about including dynamic field definitions and dynamic field values in a REST API request, see Create Master Record.

To optimize performance, MDM SaaS now has a maximum limit of 50 record-level and 50 attribute-level data access rules for each business entity. The limit includes both active and draft data access rules. When the maximum limit exceeds for a business entity, you can't create new data access rules.

If a business entity already has more than 50 record-level and 50 attribute-level rules, you can no longer create data access rules for that business entity.

For more information about the limits on data access rules, see Limits on data access rules.

You can configure conditions for relationships, relationship attributes, and related business entity attributes in data access rules. These conditions verify whether a relationship exists for a record and then control access to specific values in the record.

For example, you can create a data access rule that grants access to product records only if the product has an active Product and Category relationship. Additionally, you can set another condition to allow records only when the type attribute of the related Category business entity is set to Electronics.

For more information about configuring data access rules with conditions on relationships, relationship attributes, and related business entity attributes, see Configure the rule conditions for business entity attributes and Configure the rule conditions for relationships.

When you update or delete values of related business entity attributes that are part of a data access rule condition, or when users edit records in bulk, MDM SaaS runs the reapply data access rules job.

You can view the details of a reapply data access rules job on the My Jobs page.

For more information about the reapply data access rules job, see Monitoring the reapply data access rules job.

You can now use the Manage Shared Objects privilege to determine whether a user role can update the sharing settings of shared objects, such as dashboards, saved searches, and search templates in business applications. This privilege also grants the ability to edit and delete shared objects.

For more information about configuring the privilege for managing shared objects, see Configuring privileges for managing shared objects.

When you configure a business application, you can specify a URL field to display preview images for records. The business application displays these images on the related records and search results pages.

For more information about configuring business application, see Configuring applications.

You can now configure a match model to use geographic coordinates, such as latitude, longitude, and elevation, and match source records based on their proximity. For example, you can match source records with geographic coordinates that fall within a radius of 1000 meters.

For more information about using geographic coordinates in a match model, see Geocode field type.

You can now enable an existing business entity to save records that contain validation errors without purging data.

For more information about the business entity properties, see Business entity properties.

In Operational Insights, you can now view the total number of code values in an organization and the number of code values in each code list. You can also download the metrics as a CSV file.

The Overview page displays the usage statistics of Business Applications and Reference 360 separately.

The following image shows the usage statistics of Reference 360:

The responses of Read Master Record by Business ID and Read Master Record by SourcePKey REST APIs now include the ruleAssociation array. The ruleAssociation array includes data enrichment and validation details, such as rule IDs, trust score downgrades, and failed data enhancement rules.

For more information about the Read Master Record by Business ID and Read Master Record by SourcePKey APIs, see Business entity record APIs.

You can now configure the retention period for the history of master data to comply with data retention policies. The retention period can be up to seven years. Historical data that's older than the retention period is permanently deleted and can't be restored.

For more information about configuring the retention period for historical data, see Configuring retention periods for historical data.

You can now purge deleted source records of a specific business entity to permanently remove incorrectly loaded source records, comply with privacy regulations, and retire source systems. Purge deleted source records along with their dependencies, such as relationships, inactive master records, and history.

For more information about purging deleted source records, see Purging data.