A cluster is a set of records in a database table that share similar or identical data values. A developer defines the criteria that sort the records into clusters. If you believe that a record does not belong in the current cluster, use the Discovered Clusters options to find the correct cluster. If you believe that another cluster contains a record that belongs in the current cluster, use the Discovered Clusters options to find the correct cluster.

When you work on a cluster, use the preferred record to define the most version of the business entity that the cluster represents. The preferred record is not necessarily the final version of the record. Another user or another data process might work on the cluster after you complete the task.

When you update the preferred record, you update a record in the exception database that represents the preferred form of the records in the cluster. You do not update the source data in the cluster.

When you set the status of a cluster, you can indicate that you reviewed the cluster. The review status does not describe the accuracy or the data quality of the preferred record in the cluster.

As a best practice, mark every cluster that you examine as reviewed. The status confirms to a user in a downstream task that another user examined the cluster. When you update the data in a record, mark the record as reviewed regardless of the presence or absence of another status indicator on the record.

The audit trail stores every change that a user makes to the preferred record. The audit trail does not store changes to the cluster data.

The data that you work on can pass to a task that corrects data or a task that reviews data. For example, a developer who configures a Human task in a workflow might specify multiple correct exceptions tasks in sequence. The developer might follow a review duplicates task with a correct duplicates task.