21Duplicate Resolution Setup

This chapter contains the following:

Duplicate Resolution Simplified Profile Options

How You Setup Duplicate Resolution Simplified Profile Options

You can configure the duplicate resolution simplified profile options in the Setup and Maintenance work area using the following:

  • Offering: Customer Data Management

  • Functional Area: Customer Hub

  • Task: Manage Customer Data Management Options

You can use these profiles options to specify:

  • Tuning

    You can use this group of profile options to fine-tune the performance of your duplicate resolution processes. These settings work together to provide multiple ways to optimize your performance based on your implementation scenario, project phase, and data shape. The profile options under this category are:

    • Maximum Concurrent Merge Jobs Setting

    • Merge Mode Setting

    • Merge Request Job Size Setting

    • Merge Scope Setting

    • Merge Request Notifications

  • Duplicate Resolution Control

    Use the profile options belonging to this category to control the flow and level of automation of your duplicate resolution processes. These settings allow you to define where merge requests can originate and when data stewards need to be involved in duplicate resolution activities. The profile options under this category are:

    • Autolink Threshold Setting

    • Automerge Threshold Setting

    • Customer Center Merge Requests Setting

    • Default Resolution Type Setting

    • User Merge Handling Setting

  • Merge Behavior

    You can use this set of profile options to configure how the merge process handles the records in a duplicate resolution request. These settings allow you to control the processing logic that governs the final outcome of a merge request, such as which record is retained as the master and how the process derives its final attributes. The profile options under this category are:

    • Agreement Rules Type Setting

    • Attribute Selection Type Setting

    • Enable Attribute Source Tacking Setting

    • Master Record Selection Setting

    • Merge Identical Child Records Setting

    • Add Groovy to Attribute Selection Setting

You can find more details about the duplicate resolution simplified profile options in the individual topics about them.

You can use the Merge Scope setting to specify the business areas to be processed during a merge. This setting optimizes the size of the merge memory and execution profile and application performance.

You can specify any of these areas as the merge scope:

  • Customer data management specific areas: Merges Customer Data Management foundation entities such as Organizations, People, Addresses, Phone Numbers, and Email Addresses.

  • Customer data management specific areas with restrictions: Merges the same entities as the CDM scope. However, processing throughput is maximized by not invoking survivorship rules, integration events, or extended processing logic. You can use this option for high-volume data initialization scenarios.

  • All customer relationship management related areas: Merges Customer Data Management foundation entities and transfers CRM transactional data, such as Opportunities, Activities, or Service Requests, from duplicate records to the master record.

  • All functional areas: Merges Customer Data Management foundation entities and all merge-enabled entities on the point of deployment.

Before specifying the merge scope, you should consider these points:

  • Select the appropriate merge scope to get the best performance.

  • When you use Customer Data Management specific areas with restrictions merge scope, you must only select compatible options for other settings:

    • Master Record Selection can't be survivorship rule.

    • Attribute Selection Type can't be Oracle business rules.

    • Agreement Rules Type can't be Oracle business rules.

You can use the Merge Mode setting to select the optimized mode for merge to prevent the triggering of non-essential business events. This setting controls whether the merge uses preconfigured processing logic or workflows and generates integration events for Oracle Integration Cloud services.

Ideally, you should enable optimized mode for merge to improve application performance when:

  • you're not integrating merge events with external systems.

  • you don't need groovy scripts or object workflows to run when a master record is updated by a merge.

You can use the Merge Request Job Size to specify the number of merges that each merge job can handle. A greater number of merge requests per merge job may increase merge processing throughput when the Merge Mode is optimized or the Merge Scope is set to Customer data management specific areas with restrictions.

Consider these points before specifying the merge request job size:

  • The default value is 100 merge requests per merge job.

  • Increasing the number of merge requests per merge job can be helpful during high-volume data initialization scenarios when processing the duplicate resolution queue is a high priority.

  • The Merge Request Job Size setting and the Maximum Concurrent Merge Jobs setting work together to let you have a fine-grained control of the merge system.

  • Setting no value (null) for the Merge Request Job Size setting distributes all pending merge requests to the available Merge Request Jobs. If the ratio of merge request to merge jobs is too high, system performance may be adversely affected.

Controls whether notifications are sent when duplicate resolution requests are assigned and processed.

The options are:

  • Send notifications for new requests: User created merge requests are created with the Send Notifications parameter set to Yes.

  • Don't send notifications for new requests: User created merge requests are created with the Send Notifications parameter set to No.

  • Don't send any notifications: Merge notifications aren't sent regardless of the Send Notifications parameter value on individual merge requests.

Consider these points:

  • The Send Notifications parameter of merge requests created through the Duplicate Identification Batch process can be set at the Duplicate Identification Batch level.

  • The Send Notifications parameter value of individual merge requests can be modified on the Duplicate Resolution list page.

You can use the Maximum Concurrent Merge Jobs setting to control the number of merge jobs that can be processed at any given time. If you don't set the maximum limit, all merge jobs are submitted for concurrent processing. A greater number of concurrent merge jobs may clear a duplicate resolution request queue more quickly but may impact other processes and functions that use customer records.

Before specifying the limit for Maximum Concurrent Merge Jobs, you must consider these points:

  • The default value is 10 concurrent merge jobs.

  • Increasing the number of concurrent merge jobs can be helpful during high-volume data initialization scenarios when processing the duplicate resolution queue is a high priority.

  • The Maximum Concurrent Merge Jobs setting and the Merge Request Job Size setting work together to let you control the merge system better.

Controls which duplicate resolution process type are assigned to new duplicate resolution requests.

The options are:

  • Merge: New duplicate resolution requests are queued for merging the duplicates into one master record.

  • Link: New duplicate resolution requests are queued for linking the duplicates to each other without merging the records. The records to remain active.

  • Generic: The data steward selects the duplicate resolution process type before processing the resolution requests.

Consider these points:

  • To implement automatic duplicate resolution request processing, you must select either Merge or Link for the Default Duplicate Resolution setting.

  • A data steward can change the duplicate resolution request type while reviewing a duplicate resolution request.

Defines the match score at or above which a duplicate resolution request of type Merge is processed without requiring a data steward to review the request.

Consider these points:

  • The highest possible match score is 100. So, if you set this value to 101, you can prevent automatic Merge processing.

  • Use this setting only when the Default Duplicate Resolution type is Merge.

Defines the match score at or above which a duplicate resolution request of type Link is processed without requiring a data steward to review the request.

Consider these points:

  • The highest possible match score is 100. So, if you set this value to 101, you can prevent any automatic Link processing.

  • Use this setting only when the Default Duplicate Resolution type is Link.

Controls whether you can submit merge requests directly from the Customer Center Account and Contact list pages.

Consider these points:

  • If this option is enabled, the User Merge Handling setting controls whether or not those requests require a data steward's review before being processed.

Controls whether manually created merge requests are processed automatically or require review by a data steward. The options are:

  • Allow Processing Without Approval: Manually created merge requests are processed automatically.

  • Process Subject To Approval: Data steward reviews manually created merge requests before processing.

Consider these points:

  • Use the Create Resolution Request task in Party Center pages or through the Account and Contact list pages in Customer Center if Customer Center Merge Requests have been enabled to create Manual merge requests.

Controls the method used to identify which record in a duplicate set becomes the master during a merge. The options are:

  • Select master record using survivorship rule: Logic configured with Oracle business rules using the Manage Survivorship Rules setup task determines the master.

  • Select the oldest record as master: The record with the earliest creation date is the master.

  • Select the latest record as master: With the most recent creation date is the master.

  • Select master based on duplicate identification results: Internal logic of the duplication identification process determines the master.

  • Select master record using Data Quality Rules: Logic configured with Application Composer Data Quality Rules determines the master.

Consider these points:

  • The Select the older record as master and Select the latest record as master options use optimized internal processes and may offer the best performance.

  • Master Record Selection can't be survivorship rule or Data Quality Rules if the Merge Scope has been set to Customer data management specific areas with restrictions.

  • The Duplicate Identification batch process identifies a preliminary master record, but the final determination of master record occurs within duplicate resolution processing per the Master Record Selection Setting. Select the Select master based on duplicate identification results option if you want to retain the master record selection from the duplicate identification results.

Controls the method used to prevent records from being merged into other records incorrectly. The options are:

  • Default agreement rules: Only the seeded agreement rules are processed. These rules can't be edited or disabled.

  • Default agreement rules with Oracle business rules: In addition to the default rules, merge incorporates logic written with Oracle business rules using the Manage Agreement Rules setup task.

  • Default agreement rules with Data Quality Rules: In addition to the default rules, merge incorporates logic written with Application Composer Data Quality Rules.

Consider these points:

  • You can't use Oracle business rules to configure agreement rules or Data Quality Rules to configure agreement rules, if you have set the Merge Scope to Customer data management specific areas with restrictions.

Controls whether the merge process merges or transfer certain types of child records when they have the same values. This setting currently controls the processing of addresses, phone contact points, and email contact points.

Controls the method used to coalesce attribute values from the different records in a merge set onto the master record. The options are:

  • No attribute survivorship rules selected: Merge only replaces null values on the master with non-null values from the duplicates.

  • Use source confidence with oldest record as the tie breaker: In addition to replacing nulls with non-nulls, merge picks the attributes for the master based on the source confidence values configured using the Manage Source System Confidence setup task. In the case of multiple records in the duplicate set sharing the highest source confidence value for a given attribute, the value created at the earliest point in time is selected.

  • Use source confidence with newest record as the tie breaker: In addition to replacing nulls with non-nulls, merge picks the attributes for the master based on the source confidence values configured using the Manage Source System Confidence setup task. In the case of multiple records in the duplicate set sharing the highest source confidence value for a given attribute, the value created at the most recent point in time is selected.

  • Use Oracle business rules: In addition to replacing nulls with non-nulls, merge picks the attributes for the master based on logic configured with Oracle business rules using the Manage Survivorship Rules setup task.

Consider these points:

  • The source confidence-based survivorship methods use optimized internal processes and may offer the best performance.

  • The Attribute Selection Type can't be Oracle business rules if the Merge Scope is set to Customer data management specific areas with restrictions.

Controls whether the attribute-level change by source system is tracked. This tracking is required for survivorship processes that use source confidence configuration to determine which attribute values in a duplicate set are ultimately written onto the master record.

Consider these points:

  • The 'Use source confidence with oldest record as the tiebreaker' and 'Use source confidence with newest record as tiebreaker' attribute selection options require Attribute Source Tracking to be enabled.

  • Attribute selection options that use Oracle Business Rules can be used without enabling Attribute Source Tracking but those rules can't access source confidence values.

  • Once enabled, Enable Attribute Source Tracking can't be disabled because breaks in the source tracking history invalidate source confidence-based logic.

Controls whether logic written with Application Composer Data Quality Rules are used to determine which attribute values are selected for the master record. The options are:

  • No: Use only the option selected for the Attribute Selection Type setting to determine which attribute values are selected for the master record.

  • Yes: Combine logic written with Application Composer Data Quality Rules with the option selected for the Attribute Selection Type setting to determine which attribute values are selected for the master record.

Consider these points:

  • You can't combine Data Quality Rules with the Oracle business rules Attribute Selection Type setting option.

You can use the Run Request Dispatcher process to manage and monitor cleansing and duplicate identification batches, and duplicate resolution requests.

Run the request dispatcher process in the following modes:

  • Basic: To submit the request dispatcher job for immediate processing.

  • Advanced: To schedule the process to run either immediately or at specified intervals, such as every hour or every day.

Set Up Duplicate Resolution Using Groovy Scripts

Overview of Duplicate Resolution Setup Using Groovy Script

Duplicate resolution is a set of processes that you can use, after duplicate records are identified, to consolidate those records. You can resolve duplicates in two ways, either by linking them or by merging them. Linking involves associating the duplicate records. The linked records are treated as unique records in the data registry, and have their own unique identifiers. Merging involves combining duplicate records into one new master record.

You can setup linking by configuring a couple of profile options discussed in the topic Duplicate Resolution Simplified Profile Options. However, the setup for merging is a bit more elaborate. It consists of configuring logic to:

  • Determine which record from a set of identified duplicates should be designated as the master record. You can set this up by configuring Set Master Record Rules.

  • Determine which attribute value instances from across the set of duplicates the master record should contain. You can set this up by configuring Set Attribute Value Rules. The Set Master Record Rules and Set Attribute Value Rules are collectively called Survivorship Rules.

  • Determine whether the merge is violating any of the conditions under which a merge should be prohibited. You can set this up by configuring Agreement Rules.

You can easily setup survivorship and agreement rules using Groovy Script in Application Composer. If you already have defined survivorship and agreement rules without using the Groovy Scripts, you can migrate them to Groovy Script incrementally. For example, you could continue to use your existing agreement rules while also using Groovy Script for your set master rules.

How You Enable Groovy Script-based Survivorship and Agreement Rules

Before you can start using groovy scripts to configure survivorship and agreement rules, you must enable groovy scripting in Setup and Maintenance.

Follow these steps to enable Groovy Script-based survivorship and agreement rules:

  1. In the Setup and Maintenance work area, go to the following:

    • Offering: Customer Data Management

    • Functional Area: Customer Hub

    • Task: Manage Customer Data Management Options

  2. In the Merge Behavior section, select the groovy script options as the value for one or more of the following fields as required:

    • Master Record Selection: Select the Select master record using groovy scripts option to define the rules for selecting master records using Groovy Scripts.

    • Attribute Selection Type: To define attribute selection rules using Groovy Scripts, select the following options:

      • Select either Use source confidence with newest record as the tie breaker or Use source confidence with oldest record as the tiebreaker.

      • Select Yes for the Add Groovy to Attribute Selection field.

    • Agreement Rules Type: Select the Default agreement rules with groovy scripts option to define agreement rules using Groovy Scripts.

Create an Application Composer Sandbox

The configuration of Groovy Script survivorship and agreement rules is done in Application Composer using the standard Unified Sandbox framework for developing and testing your scripts. We recommend that you create a separate, dedicated sandbox for survivorship and agreement rules rather than combine survivorship and agreement rule configuration with other types of Application Composer configuration activities. This approach gives you the greatest flexibility for iterative design, testing, and deployment of your survivorship and agreement rules.

To create an Application Composer Sandbox:

  1. Click Navigator > Configuration > Application Composer > Sandboxes

  2. Click Create Sandbox.

  3. Specify a name and select Application Composer under All Tools. Also select the Publishable option as Yes.

  4. Click Create and Enter.

  5. Click the Application Composer icon.

  6. Go to the Advanced Setup task list.

  7. Select Data Quality Rules.

    You should be able to see six predefined templates for survivorship rules of the type set master and set attributes and agreement rules. You should be able to see three rules for the Contact (Person) entity and three for the Account (Organization) entity.

You are now ready to configure the survivorship or agreement rules using Groovy Scrip for accounts or contacts. For more information about creating sandboxes, see the Related Topics section.

Configure Predefined Data Quality Rules to Your Requirements in Application Composer

You can configure predefined data quality rules to your requirements in application composer by completing the following steps:

  1. In your Sandbox dedicated for Data Quality rules, click the Application Composer icon.

  2. Go to Advanced Setup.

  3. Click Data Quality Rules to view the predefined data quality rules. You should be able to see six predefined templates for data quality rules, three for the Contact (Person) entity and three for the Account (Organization) entity. These templates are:

    • ContactSetMaster: Configure rules for determining the master record in contact merges.

    • ContactSetAttribute: Configure attribute survivorship rules for contact merges.

    • ContactMergeAgreement: Configure merge agreement rules for contact records.

    • AccountSetMaster: Configure rules for determining the master record in account merges.

    • AccountSetAttribute: Configure attribute survivorship rules for account merges.

    • AccountMergeAgreement: Configure merge agreement rules for account records.

  4. To configure the merge processing logic for any of these templates, you can:

    • Click the required template.

    • Select the desired row and click Actions > Edit.

  5. Create and save your scripts in the Groovy Script editing interface that's displayed when you click edit for a given survivorship or agreement rule.

Configure Groovy Script Based Set Master Record Rules

In this example, you will learn how to create a set master record rule to select the master record in an account merge based on the source system references of the records in the merge request. The logical requirements of the scenario are as follows:

  • Records integrated with RNOW source system are the top priority to be master record.

  • Records integrated with PSFT source system are the second priority to be master record.

  • If multiple records are present from a prioritized source system, use the most recently updated record as the tiebreaker.

  • If neither PSFT- nor RNOW-integrated records are present in the merge, take whatever record had been designated as master by the upstream process.

Steps to Perform

  1. Enable Groovy Scripts to select master records:

    1. In the Setup and Maintenance work area, go to the following:

      • Offering: Customer Data Management

      • Functional Area: Customer Hub

      • Task: Manage Customer Data Management Options

    2. In the Merge Behavior section, select the Select master record using groovy scripts option for the Master Record Selection field.

  2. Create an Application Composer sandbox. Refer to the Create an Application Composer Sandbox topic for the steps.

  3. Populate the sample script in the AccountSetMaster template:

    • Navigate to Advanced Setup > Data Quality Rules.

    • Click AccountSetMaster.

    • Copy and paste the code given in the Sample Code section in the Edit Data Quality Rules page.

    • Click Save and Close.

  4. Test the code. Refer to the Test the Survivorship and Agreement Rules Configuration topic to test the code.

  5. Deploy the Code, after you're satisfied with the results of the Set Master Record Rules. See the topic: Deploy the Survivorship and Agreement Rules Configuration.

What the Sample Script Does

The script begins by calling the getRows() input function to access the records in the merge request. Next, the script loops through the records in the merge request to inspect which source system reference assignments exist for each record. When a prioritized source system reference assignment, for example PSFT or RNOW, is identified, the row is added to the list of records having the given source system reference assignment.

Once all the rows in the merge request have been tested for their source system reference values, the script tests whether any records from the top priority source system reference were found. If records are found in the top priority list, they're sorted by last updated date. Then the most recently updated record having the highest priority source system reference is designated to become the master record. If no record with the top priority source system reference was found, the script tests to see if any records with the second priority source system reference were found, following the same process as was used for the top priority source system.

Finally, the script calls the selectMaster() output function to designate the master record. If a top-priority or second-priority record was identified earlier in the script, that record is provided to the selectMaster() function. If no priority record was identified, then selectMaster() is called with the getSurvivor() function to specify that whatever record had been identified as the master upstream of the script should be retained as the master.

Sample Code

try {
  def mergeRows = getRows();
  def rowMaster = false;
  def osrMap = ['RNOW':[], 'PSFT':[]];
  for (row in mergeRows) {
    def osrRows = row.getAttribute("OriginalSystemReference");
    osrRows.reset();
    while(osrRows.hasNext()){
      def osrRow = osrRows.next()
      if (osrRow.OrigSystem == "RNOW") {
          osrMap['RNOW'].add(row);
      } else if (osrRow.OrigSystem == "PSFT") {
          osrMap['PSFT'].add(row);
      }
    }
  }

  if (rowMaster==false && osrMap['RNOW'].size() > 0) {
    rowMaster = osrMap['RNOW'][0];
    for (row in osrMap['RNOW']){
      if (row.LastUpdateDate > rowMaster.LastUpdateDate) {
        rowMaster = row;}
    }
  }

  if (rowMaster==false && osrMap['PSFT'].size() > 0) {
    rowMaster = osrMap['PSFT'][0];
    for (row in osrMap['PSFT']){
      if (row.LastUpdateDate > rowMaster.LastUpdateDate) {
        rowMaster = row;}
    }
  }

  if(rowMaster){
    selectMaster(rowMaster);}
  else{
    selectMaster(getSurvivor());}
}

catch(Exception e) {
  def sMsg = "Exception in Account Set Master: " + e.getMessage();
  println(sMsg);
}

Configure Groovy Script Based Set Attribute Value Rules

In this example, you will learn how to create a set attribute value rule to override the standard attribute source confidence-based survivorship processing with groovy script based on the classification code assignment of the records. The logical requirements of the scenario are as follows:

  • If the merge contains a record that has been classified as OFN Category One account, use that OFN Category One record's value for a set of key fields regardless of the attribute source confidence score.

  • If multiple rows in the merge have been classified as OFN Category One, use the attribute values from the most recently updated row.

Steps to Perform

  1. Enable Groovy Scripts to select master records:

    1. In the Setup and Maintenance work area, go to the following:

      • Offering: Customer Data Management

      • Functional Area: Customer Hub

      • Task: Manage Customer Data Management Options

    2. In the Merge Behavior section, select the following options:

      • Select either Use source confidence with newest record as the tie breaker or Use source confidence with oldest record as the tiebreaker for the Attribute Selection Type field.

      • Select Yes for the Add Groovy to Attribute Selection field.

    3. Create an Application Composer sandbox. Refer to the Create an Application Composer Sandbox topic for the steps.

  2. Populate the sample script in the AccountSetAttribute template:

    1. Navigate to Advanced Setup > Data Quality Rules.

    2. Copy and paste the code given in Sample Code section in the Edit Data Quality Rules page.

    3. Click Save and Close.

  3. Test the code. Refer to the Test the Survivorship and Agreement Rules Configuration section to test the code.

  4. Deploy the code after you're satisfied with the results of the attribute value rules, you can. See the topic: Deploy the Survivorship and Agreement Rules Configuration.

What the Sample Script Does

The script begins by calling the getRows()input function to access the records in the merge request. Next, the script loops through each of the row records and accesses its Code Assignment collection. The script then loops through the code assignments to test whether the specified code assignment value is present. When a row having the specified code assignment is identified, the row is copied into an array of prioritized records for subsequent processing.

Once all the rows in the merge request have been tested for their code assignment values, the list of prioritized records is sorted based on the records' last update date. Finally, the script identifies the most recently updated row having the specified code assignment value. After this row is identified, the script calls the selectAttribute() output function to designate that priority row as being the attribute value source for a set of defined attributes.

Sample Code

try {
  def rowDuplicates = getRows();
  def rowPriorities = [];
  def exceptionAttributes = ['BusinessScope', 'CeoTitle'];
  def CAs;
  def CAi;
  for(row in rowDuplicates){
    CAs = row.getAttribute("CodeAssignment");
    if(CAs){
      for(CA in CAs){
          CA.reset();
          while(CA.hasNext()) {
            CAi = CA.next();
            if(CAi.ClassCategory == "OFN" && CAi.ClassCode == "OFN1") {
              rowPriorities.add(row);}
          }
       }
    }
  }

  if(rowPriorities.size()){
    def rowPriority = rowPriorities[0];
    for (row in rowPriorities){
      if (row.LastUpdateDate > rowPriority.LastUpdateDate){
        rowPriority = row;}
    }

    for (a in exceptionAttributes){
      selectAttribute(a, rowPriority);
    }
  }
}

catch(Exception e) {
  def sMsg = "Exception in Account Set Attribute: " + e.getMessage();
  println(sMsg);
}

Configure Groovy Script Based Agreement Rules

In this example, we are operating in a complex business ecosystem where it's not always appropriate to merge certain accounts that have been identified as duplicates. When the conditions that prohibit a merge from happening are encountered, the data steward needs to see an informative message explaining exactly which records blocked the merge, and for what reasons. The conditions that can prevent a merge are as follows:

  • A victim record is integrated with the Legal Hold system

  • A victim record has a Certification Score value of 100

Steps to Perform

  1. Enable Groovy Scripts to select master records:

    1. In the Setup and Maintenance work area, go to the following:

      • Offering: Customer Data Management

      • Functional Area: Customer Hub

      • Task: Manage Customer Data Management Options

    2. In the Merge Behavior section, select the Default agreement rules with groovy scripts option for the Agreement Rules Type field.

  2. Create an Application Composer sandbox. Refer to the Create an Application Composer Sandbox topic for the steps.

  3. Populate the sample script in the AccountMergeAgreement template:

    1. Navigate to Advanced Setup > Data Quality Rules.

    2. Click AccountMergeAgreement.

  4. Copy and paste the code given in the Sample Code section in the Edit Data Quality Rules page.

  5. Click Save and Close.

  6. Test the code. Refer to the Test the Survivorship and Agreement Rules Configuration topic to test the code.

  7. Deploy the code after you're satisfied with the results of the agreement rules. See the topic: Deploy the Survivorship and Agreement Rules Configuration.

What the Sample Script Does

The script begins by calling the getVictims()input function to access the non-master records in the merge request. Note that the result of a Set Master groovy scripts is expressed in getSurvivor() and getVictims() responses in Agreement Rule and Attribute Selection scripts. Next, the script loops through each of the row records to test for the two different conditions that would lead to the merge being rejected. The first test is to evaluate the source system reference assignments of the records to determine if the record is integrated with the Legal Hold system. The second test is to check the Certification Level value of the victim records. If a given record matches either of the tests, a partial rejection message is added to the vetoMessages array.

After all the victim rows in the merge request have been tested, the script checks to see if the vetoMessages array has any data in it. If it does, then a final rejection message is constructed from the data in the vetoMessages array and the merge is rejected with that constructed message being displayed to the data steward in the duplicate resolution UI.

Sample Code

try {
  def rowVictims = getVictims();
  def sMsg = "";
  def rejectMsg = "";
  def vetoMessages = [];
  for (row in rowVictims){
    def OSRs = row.getAttribute("OriginalSystemReference");
    OSRs.reset();
    sMsg = "";
    while(OSRs.hasNext()) {
      def OS = OSRs.next();
      if (OS.getAttribute("OrigSystem") == "LEGAL_HOLD" && sMsg == "") {
        sMsg = "A legal hold has been placed on Account " + row.getAttribute("PartyNumber");
        vetoMessages.add(sMsg);}
      }
      sMsg = "";
      if (row.getAttribute("CertificationLevel") == "100") {
        sMsg = "A Certification Level of 100 was found on Account " + row.getAttribute("PartyNumber");
        vetoMessages.add(sMsg);}
  }

  if (vetoMessages.size()) {
    rejectMsg = "Merge rejection reasons: ";
    vetoMessages.eachWithIndex { item, index ->
       rejectMsg += ((index +1) + ") " + item + " ");
    }
    rejectRequest(rejectMsg);
  }
}

catch(Exception e) {
  def sMsg = "Exception in Account Merge Agreement: " + e.getMessage();
  println(sMsg);
}

Test the Survivorship and Agreement Rules Configuration

You can test your Groovy Script-based survivorship and agreement rules configuration while working inside of the sandbox by creating a Test Merge Request in the Duplicate Resolution work area. A Test Merge Request invokes whatever survivorship and agreement rules have been configured inside the current sandbox. For more information about creating test merge requests, see Related Topics section.

After you have identified potential duplicates in your database through a duplicate identification batch, you can resolve these duplicate sets by creating and submitting a duplicate resolution request.

To create and submit a resolution request:

  1. Navigate to the Create Resolution Request UI page as follows: Navigator > Customer Data Management > Duplicate Resolution > Tasks

  2. Search for and multi-select the duplicate records using the shift key.

  3. Click Create Request.

  4. Click Test Merge and click OK.

    You can optionally select one of the records as master. Once the request is submitted, the application generates a Request ID, which you can use to track the status of the duplicate resolution process.

  5. You can tweak your survivorship and agreement rules configuration and retest your code using new test merge requests to ensure that the code is working as expected.

    Note: This process tests the merge request configuration without changing your application data.

Deploy the Survivorship and Agreement Rules Configuration

When you're satisfied with your configured survivorship and agreement rules, you can deploy the configuration by using the standard sandbox publication process. When you publish the sandbox, whatever Groovy Script-based rules were previously in the mainline configuration are replaced with whatever scripts are in the sandbox. Once the sandbox has been published, the Request Dispatch scheduled process begins to use the new Groovy Scripts during the processing of regular merge requests.

To publish a sandbox to deploy your survivorship and agreement rules configuration:

  1. Click Navigator > Configuration > Sandboxes

  2. On the Sandboxes page, click the name of the sandbox you want to publish.

  3. Click Publish.

    Note: The Publish button might be disabled for your sandbox because of various reasons. For example, you haven't yet made any changes in your sandbox, or the Control Publish Sandbox Action in Production Environment profile option (FND_ALLOW_PUBLISH_SANDBOX) is set to No.
  4. Click Continue to Publish. The sandbox is published.

  5. Click Done.

Best Practices for Configuring Groovy Scripts Based Survivorship and Agreement Rules

In this topic we discuss the best practices for configuring groovy scripts.

  • If you configure your implementation to use Groovy Scripts for Set Master rules, merges aren't processed until a valid Set Master script has been deployed.

  • Any survivorship rules written using the Manage Survivorship Rules setup task which uses the Oracle Business Rules framework, continues to function if you don't enable groovy script survivorship rules.

  • For a given survivorship process type, such as Set Master or Agreement Rules, you can either use Groovy script or Oracle Business Rules. You can't combine the two frameworks for a single process type. For example you can't define one Set Master rule using Groovy Script and another Set Master rule using Oracle Business rules.

  • You can combine Oracle Business Rules and Groovy script between different survivorship process types, such as using Oracle Business Rules for Set Master logic and Groovy script for Set Attribute logic.

  • For best performance with attribute survivorship processing, try to use attribute source confidence as much as possible for your Set Attribute survivorship logic.

  • Select one of the Use source confidence Attribute Selection Type options from the Manage Customer Data Management Options setup page.

  • If needed, use Groovy script along with your source confidence configuration to handle exception scenarios.

Overview of Groovy Scripting Functions

Groovy Script support for configuring survivorship and agreement rules is based on a specific set of functions that let you interact with the data records in the context of a merge request. These functions are of the following categories:

  • Functions that let you inspect the records in the merge requests

  • Functions that let you define the result of the merge request

These categories of specialized functions help you to create survivorship and agreement rules using standard Groovy Script syntax and operations.

Input Functions

These functions provide the data that your survivorship and agreement rules evaluate. Generally, these functions are called at the beginning of your script to instantiate the information required to determine the proper merge process outputs.

getRuleType()

This function lets you determine the functional context of the script. This function returns SetAttribute, SetMaster, or Agreement depending on which type of script calls it. It's generally not necessary to programmatically determine the rule type because the script types are presented as distinct functions within the Application Composer Data Quality Rules task. But there may be cases where it's helpful for logging or testing.

getObjectType()

This function lets you determine what type of party the merge request is processing. This function returns PERSON or ORGANIZATION depending on which type of script calls it. It's generally not necessary to programmatically determine the object type because the scripts for Persons and Organizations are clearly differentiated as distinct functions within the Application Composer Data Quality Rules task. But there may be cases where it's helpful for logging or testing.

getSurvivor()

This function lets you access the data record that has been identified as the master record for the merge request. The function is called without parameters and it returns a single Row object that contains the details of the master record. The following example shows a typical usage of this function:

 def rowSurvivor = getSurvivor();
  def survivorName = rowSurvivor.getAttribute("OrganizationName");
  // etc...

getVictims()

This function lets you access the set of data records that have been identified as the non-master records for the merge request, which are also referred to as victim records because the merge process inactivates them. This function is called without parameters and it returns a list of row objects consisting of one list entry for each victim record. It's important to note that the getVictims list isn't an ADF recordset object. ADF recordset functions such as reset() and first() don't work with the list. The following example shows a typical usage of this function:

 getVictims()
def rowVictims = getVictims();
   def victimName;
   for (victim in rowVictims) {
       victimName = victim.getAttribute("OrganizationName"); }
   // etc...
 

getRows()

This function lets you access the full set of customer records for the merge request, which is the union of the survivor and victim sets of rows. This function is called without parameters and it returns a list of row objects consisting of one list entry for each victim record. Like the getVictims function, it's important to note that the getRows list isn't an ADF recordset object. ADF recordset functions such as reset() and first() don't work with the list. The following example shows a typical usage of this function:

def rowDuplicates = getRows()
   def duplicateName;
   for (duplicate in rowDuplicates) {
      duplicateName = duplicate.getAttribute("OrganizationName"); }
    // etc...

getSourceInfo(Row row, String attributeName)

This function lets you access information about which source system provided the current value of an attribute for a given survivor or victim row. This function is called using the following parameters:

  • A row object for the victim or survivor row of interest

  • The name of a source-confidence configured attribute

This function returns a source information record for the attribute in question. The structure of the source information record is as follows:

Attribute Definition Example
RecordId

The party ID of the person or organization record referenced by the row object parameter.

300100184760397

AttributeName

The name of the attribute parameter.

OrganizationName

AttributeValue

The current value of the attribute on the row.

Pinnacle Systems

Source

The code of the registered source system for the attribute value.

RNOW

SourceConfidenceLevel

The configured attribute source confidence value of the given attribute for the given source system.

90

SourceUpdateDate

The time stamp when the person or organization record was updated with the current value.

1/24/2020 11:48:03 PM

Note: The getSourceInfo function is only available for attributes that have been configured with source system confidence using the Manage Source System Confidence setup task.

The following example shows a typical usage of this function:

    def rowDuplicates = getRows();
    def rowSource;
    def bestSource;
    def bestValue;
    bestSource = getSourceInfo(rowDuplicates[0],"OrganizationName");
    for (row in rowDuplicates) {
      rowSource = getSourceInfo(row,"OrganizationName");
      if(rowSource.SourceConfidenceLevel > bestSource.SourceConfidenceLevel) {
        bestSource = rowSource;
      }  
    }
    bestValue = bestSource.AttributeValue;

Output Functions

Output functions create the final behavior of the merge process based on the logic of a survivorship or agreement rule script. Generally, these functions are called at the end of the script after the data provided by the input functions has been evaluated with scripted logic.

selectMaster(Row row)

This function is used in Contact Set Master and Account Set Master scripts to specify which record from the merge request should be retained as the master record after the merge. This function takes a data Row instance as its only parameter, and whatever row is passed to the function is the record that's retained as the master. All other records in the merge request are inactivated during merge processing. The following example shows a typical usage of this function:

...
    def masterRow = rowDuplicates[0];
    for (row in rowDuplicates) {
      if row.LastUpdateDate > masterRow.LastUpdateDate {
        masterRow = row;
      }
    }
    selectMaster(masterRow);

selectAttribute(String attributeName, Row row)

This function is used in Contact Set Attributes and Account Set Attributes scripts to define which attribute value instances from across the records in the merge should be used to build the master record. This function takes the name of an attribute and a Row instance as its parameters. The value for the given parameter that's found in the given row is retained on the master record. This function is logically equivalent to using the Duplicate Resolution override flow to select the source record for a given attribute. The following example shows the syntax of this function:

    def rowDuplicates = getRows();
    def bestSourceRow;
    def fieldName = "OrganizationName";
    rowBestSource = rowDuplicates[0];
    for (row in rowDuplicates) {
       if(getSourceInfo(row, fieldName).SourceConfidenceLevel > getSourceInfo(rowBestSource, fieldName).SourceConfidenceLevel) {
          rowBestSource = row;}
    }
    selectAttribute(fieldName, rowBestSource);

overrideAttribute(String attributeName, Object attributeValue)

This function is used in Contact Set Attribute and Account Set Attribute rules to specify an attribute value for the master record, which can't be derived in the normal fashion from the records in the merge request. This function takes the name of an attribute and the value for the attribute as its parameters and sets the final value of the master record's given field to the given value. This function is logically equivalent to using the Duplicate Resolution Override flow to enter your own value for a given attribute.

Note: Ensure that the value's data type and format are correct because this function sets an externally-defined value.

The following example shows the syntax for this function:

def fieldName = "OrganizationName";
    def fieldValue = "Pinnacle Systems";
    overrideAttribute(fieldName, fieldValue);

This function is used in Contact Agreement Rule and Account Agreement Rule scripts to veto a merge request if a specified set of conditions are observed in the merge request's records. This function takes a single parameter which defines the rejection message that's displayed on the merge request if the rejection criteria are met. The following example shows the syntax for this function:

def rowVictims = getVictims;
    for (row in rowVictims) {
        if (row.value != null) {
            rejectRequest("Unable to merge contacts that this value");}
    }

Evaluating the Data

Once you have called the appropriate functions, your survivorship or agreement rules script need to evaluate the data to determine the correct merge result. This evaluation process uses standard Groovy Script operators and functions. For more information about Groovy scripts, see the Oracle Applications Cloud Groovy Scripting Reference guide.

Putting It Together

You can generally follow this pattern in groovy scripting:

  1. Call Input Functions

  2. Evaluate the Data

  3. Call Output Functions

To further illustrate this concept, the following is a simple script to determine the master record for a merge request based on the most recent Last Updated Date from the records:

/* Input Functions: call getRows() to initialize a list of the party records in the merge request and then
define a variable to designate the Master record and set it to the first record in the list of Rows */
    def rowDuplicates = getRows();  
    def masterRow = rowDuplicates[0]; 
/* Evaluate the Data: iterate through the list of records to determine if the current list item 
was more recently updated than whatever record has been designated the master.  If the current record was more recently updated, 
promote it to become the new Master */
    for (row in rowDuplicates) {
      if (row.LastUpdateDate > masterRow.LastUpdateDate) {
        masterRow = row; 
      }
    }
/* Call Output Functions: use the selectMaster() function to dictate which record from the merge set 
should become the master */
    selectMaster(masterRow);

Best Practices for Groovy Scripting

Consider the following points when planning and configuring your survivorship and agreement rules using groovy scripts:

  • The Rows returned by the getRows(), getVictims(), and getSurvivor() functions is a standard Groovy Script list object, not an Oracle ADF recordset object. You must use standard Groovy methods for traversing the recordset such as for (item in list) instead of ADF functions such as reset(), first(), or hasNext().

  • The responses of the getRows(), getVictims(), or getSurvivor() functions are cached for each script execution. So the data state of row objects of your scripts don't show any changes within the scope of a script execution.

  • The result of a Set Master script is reflected in the response to getVictims() or getSurvivor() functions called in Set Attribute or Agreement Rules scripts.

  • You can't access the Resolution Request header object in your survivorship scripts. The only supported means for initializing data objects in your scripts are the input functions described in this topic.

  • The selectAttribute() and overrideAttribute() functions can be used on top-level attributes of the Row object. Fields that contain embedded child record collections can't be manipulated with these functions.

  • You can interact with custom attributes and custom child objects by using the API name for the attribute or object that was specified when the custom entity was created in Application Composer.

  • The script fragments provided in this topic are intended to illustrate the syntax and usage of the Input and Output functions. Refer to the Sample Scripts section for examples of complete scripts.

  • Some Best Practices for writing Groovy Scripts are available in the Performance Best Practices for Using Scripts section of Performance Best Practices for Extending Oracle CX Sales and B2B Service (Doc ID 2170121.1) on My Oracle Support: https://support.oracle.com/epmos/faces/DocumentDisplay?id=2170121.1

  • The Groovy Script survivorship and agreement rule templates should only be used to configure Set Master, Attribute Survivorship and Agreement rules. Use of these templates for general processing extension or automation isn't supported and may cause incorrect or unpredictable behavior.

Set Up Duplicate Resolution Using Oracle Business Rules

Overview of Duplicate Resolution Setup Using Oracle Business Rules

An alternative to using Groovy Scripts based survivorship and agreement rules is to configure them using Oracle Business Rules. Before you process merge requests, you must configure survivorship and agreement rules. You can do this configuration in the Setup and Maintenance work area using the Manage Survivorship Rules and Manage Agreement Rules setup tasks.

Set Up Survivorship

Survivorship rules are a collection of business rules that determine the master or surviving record and its attributes during the merge operation.

Survivorship rules create the best version of a record from multiple source systems, based on business rules. You can configure survivorship rules to resolve conflicts while merging duplicate records.

Survivorship Rules Types

There are two types of survivorship rules. You can configure them based on your business needs. They are as follows:

  • Set master record: Configure the set master record rule to define the criteria for selecting the master record from a set of potential duplicate records.

  • Set attribute value: Configure the set attribute value rule to define the criteria for selecting the best attribute values from multiple input records.

Predefined Survivorship Rules

Six predefined set attribute value rules are provided ready-to-use with the application:

  • Least Recently Updated Organization Attribute (History Wins): This rule selects the organization attributes that have the oldest updated date.

  • Most Recently Updated Organization Attribute (Recent Wins): This rule selects the organization attributes that have the most recent updated date.

  • Highest Source Confidence Level Wins for Organization: This rule selects the organization attribute values that have the highest source confidence.

  • Least Recently Updated Person Attribute (History Wins): This rule selects the person attributes that have the oldest updated date..

  • Most Recently Updated Person Attribute (Recent Wins): This rule selects the person attributes that have the most recent updated date.

  • Highest Source Confidence Level Wins for Person: This rule selects the person attribute values that have the highest source confidence.

In addition, you can use predefined templates to create new Set Attribute Value rules.

To see these predefined attribute rules, click Search button on the Manage Survivorship Rules task. You can use these predefined survivorship rules as a starting point to define the criteria that's best for your business. These rules are updated with every release. You can also create, edit, and delete these rules. However, deleting an existing rule isn't recommended. By default, these predefined survivorship rules are in the inactive status and you can activate these rules from the Manage Survivorship Rules task.

How You Enable Survivorship Rules

You can enable the survivorship functionality by setting the ZCH_ENABLE_SURVIVORSHIP profile option to Yes in the Setup and Maintenance work area, using the following:

  • Offering: Customer Data Management

  • Functional Area: Customer Hub

  • Task: Manage Customer Hub Profile Options

How You Manage Survivorship Rules

You can create, edit, and delete survivorship rules in the Setup and Maintenance work area by going to the following:

  • Offering: Customer Data Management

  • Functional Area: Customer Hub

  • Task: Manage Survivorship Rules

The rules use source system confidence level and other criteria to determine the attributes of the record that should be retained from a particular source system, and are stored in the survivorship rules dictionary XML file.

Note: The application doesn't support changing survivorship rules inside the Application Composer sandbox. Therefore, the merge engine doesn't pick up the changes made to these rules inside the Application Composer sandbox. When you define custom attributes or custom objects in an Application Composer sandbox, you should Publish and Exit the sandbox before changing a survivorship rule in the Manage Survivorship Rules setup task.

This example demonstrates how to create a survivorship rule. Survivorship rules enable intelligent creation of the best version record, especially from multiple source systems, by specifying criteria for selecting the record to be retained during a merge operation.

Create A Survivorship Rule

To create a survivorship rule:

  1. In the Setup and Maintenance work area, go to the following:

    • Offering: Customer Data Management

    • Functional Area: Customer Hub

    • Task: Manage Survivorship Rules

  2. On the Manage Survivorship Rules page, click Add from the Actions menu.

  3. Enter the sample information provided in the following table on the Create Survivorship Rule page.

    Field Value

    Rule Name

    PickPersonMasterRule

    Description

    Select the master person record based on original source system of the record.

    Rule Type

    Set master record

    Note: Note: You can create the following two types of survivorship rules: Set Master Record and Set Attribute Value. You can use predefined templates to create the Set Attribute Value rules.

    Object Type

    Person

    Note: You can create a survivorship rule for the following two types of party records: Person and Organization.

  4. Click Apply. The Define Survivorship Rules: Select Master Record page appears.

Specify Criteria for Selecting the Master Record

The following are the steps to specify criteria for selecting the master record:

  1. Navigate to the Define Survivorship Rules: Select Master Record page.

  2. Enter the information provided in the following table as IF/THEN rules condition in the Define Survivorship Rules: Select Master Record page.

    Rule Condition Value

    IF Condition

    IF PersonParty is a TCHFactTypeDictionary.PersonPartyVO and there's a case where {OrigSourceSystem} != null and   OrigSourceSystem.OwnerTableId == PersonParty.PartyId and OrigSourceSystem.OrigSystem == "GSI"}

    THEN Condition

    THEN Assert new Result (name:"masterId", value:"PersonParty.PartyId)

    Note the following specification in the Define Survivorship Rules: Select Master Record page.

    • Click the + icon to add additional patterns to include additional conditions

    • Click the Surround with Parenthesis option to add more features to the conditions

    • Select the + Simple Test option to add additional clauses

    The following figure shows the Define Survivorship Rules: Select Master Record page with the Surround icon highlighted.

    The Define Survivorship Rules: Select Master Record
page with the Surround icon highlighted.

  3. Click the Advanced Settings button to verify the effective date of the rule that you're going to create.

    The following figure shows Advanced Settings icon on the Define Survivorship Rule: Select Master Record page.

    The Define Survivorship Rules: Select Master Record
page with Advanced Settings icon highlighted.

  4. Select an effective date, as appropriate. The default effective date is Always. You can select an Effective From or Effective To date, or you can select an Effective Date range.

  5. Select a priority for the rule, as appropriate.

    The default priority of the Survivorship rules is Medium. These rules get executed in the order of their priority.

  6. Ensure that the Rules Active option is selected.

    The following figure shows how the survivorship rule looks like when fully defined. The details include the rule name and the IF and THEN conditions for determining the master.

    The Select Master page with fully defined select
master record survivorship rule.

  7. Click Save and Close. You can view the newly created rule in the Manage Survivorship Rules page by searching for it.

  8. Click Submit.

    Tip: To activate the rule you must click Submit. You may have selected the Active mode, but that doesn't activate a rule unless submitted.

This procedure demonstrates how to create a survivorship rule of the type Set Master Record. You can determine survivorship at the record level using the set master record rule type. Set master rules are used in party merge to set a single record as the master record.

Create Set Master Record Rules

The input to the survivorship rule is given in the IF clause. In a set master rule, the input is a set of party records. The THEN clause contains the output that determines the master record. In the Set Master Record rule, the output is a result object that contains a specific Party ID. If multiple records with different Party IDs are returned, then it results in a conflict error. To create Set Master rules, you may perform the following steps:

To create Set Master rules, you perform the following steps:

  1. Navigate to the Manage Survivorship Rules task.

  2. Click Add. The Create Survivorship Rule page appears.

  3. Enter the information provided in the following table on the Create Survivorship Rule page.

    Field Value

    Rule Name

    PickOrganizationMasterRule

    Description

    Select the master organization record based on the specified criteria for setting the master record.

    Rule Type

    Set master record

    Object Type

    Organization

  4. Click Apply. You're taken to the Define Survivorship Rules: Select Master Record page.

In the Define Survivorship Rules: Select Master Record page, you specify criteria for picking the master record. The criteria that you define in this page determine the output of the rule.

The following topics contains three worked examples that show different ways of defining criteria in the Define Survivorship Rules: Select Master Record page to set a master records:

  • Set the Record with Oldest Creation Date as Master

  • Set the Record with D-U-N-S Number and Smallest Party ID as Master

  • Set the Record with D-U-N-S Number and Highest Number of Party Site as Master

How You Set the Record with the Oldest Creation Date as Master

This rule has a single condition to set a record that has the oldest creation date as the master.

  1. Navigate to the Define Survivorship Rules: Select Master Record page.

  2. Enter the information provided in the following table as IF/THEN rules condition in the Define Survivorship Rule: Select Master Record page.

Rule Condition Value

IF Condition

IF master is an HZ_PERSON_FactType.PersonPartyVO
and there is no case where {nonmaster == HZ_PERSON_FactType.PersonPartyVO and master.PartyId isn't nonmaster.PartyId and master.creationDate is more than nonmaster.CreationDate}

THEN Condition

THEN Assert new Result (name:"masterId", value:" master.PartyId)

The following figure displays the Define Survivorship Rules: Select Master Record page with completely filled IF and THEN rules conditions for setting a record that has the oldest creation date as the master.

Completely filled Define Survivorship Rules: Select
Master Record page to set a record that has the oldest creation date
as the master.
How You Set the Record with D-U-N-S Number and Smallest Party ID as Master

This rule identifies and returns the master record based on the following three conditions in the order of priority listed:

  1. Pick master that has D-U-N-S Number.

  2. If more than one record has D-U-N-S Number, pick one based on the smallest Party ID.

  3. If no record has D-U-N-S Number, pick one based on the smallest Party ID.

The following are the use cases for a set master record rule to pick the master based on the D-U-N-S number and the smallest Party ID.

Use Case 1

In this case, there are two records with D-U-N-S number. Therefore, the record with the smaller party ID is picked as the master record. The following table contains the sample record information for this use case.

Record Name Party ID D-U-N-S Number Master

Record 1

11

998837472

Yes

Record 2

12

null

No

Record 3

13

984939234

No

The following table lists the IF and THEN rules condition values that you must enter on the Define Survivorship Rules: Select Master Record page for this use case.

Rule Condition Value

IF Condition

Pick D-U-N-S number{IF master is an HZ_PERSON_FactType.OrganizationPartyVO
master.DUNsNumberC isn't null}
masterPartyID is the minimum of masterPartyID
where
{master= HZ_PERSON_FactType.OrganizationPartyVO and
master.DUNsNumberC isn't null}

THEN Condition

THEN 
Assert new Result (name:"masterId", value:" master.PartyId)

The following figure shows the Define Survivorship Rules: Select Master Record page with IF and THEN rules conditions for picking the record with D-U-N-S number and minimum party ID as master.

Completely filled Define Survivorship Rules: Select
Master Record page with IF and THEN rule conditions to pick the record
with D-U-N-S number and minimum party ID as master.

Use Case 2

In this case, there is no record with D-U-N-S number. Therefore, the record with smallest party ID is picked as the master record. The following table lists the sample record information for this use case.

Record Name Party ID D-U-N-S Number Master

Record 1

21

null

Yes

Record 2

22

null

No

Record 3

23

null

No

The following table lists the IF and THEN rules condition values that you must enter on the Define Survivorship Rules: Select Master Record page for this use case.

Rule Condition Value

IF Condition

Pick D-U-N-S number
{IF master is an HZ_PERSON_FactType.OrganizationPartyVO
master.DUNsNumberC isn't null}
and 
masterPartyID is the minimum of masterPartyID
where
{master= HZ_PERSON_FactType.OrganizationPartyVO and
master.DUNsNumberC isn't null}

THEN Condition

THEN 
Assert new Result (name:"masterId", value:" master.PartyId)

The following figure displays the Define Survivorship Rules: Select Master Record page with completely filled IF and THEN rules conditions to set the record that has the smallest party ID as the master when no record with D-U-N-S number is found.

Define Survivorship Rules: Select Master Record
page with the IF and THEN rule conditions to pick the record with
no D-U-N-S number and minimum party ID as master.

In this example, you have created two set master rules for Organization. First rule is for the cases where the input records have at least one record with D-U-N-S number. The second is for the case where no records have D-U-N-S Number.

Note: You can activate more than one survivorship rule at a time. When you activate multiple rules, make sure that the rules aren't conflicting and the conditions in the rule are set according to the priority.
How You Set the Record with D-U-N-S Number and Highest Number of Party Sites as Master

This rule identifies and returns the master record based on the following three conditions in the order of priority listed:

  1. Pick master that has D-U-N-S Number.

  2. Pick master that has more party sites.

  3. Pick master that has the smallest Party ID.

The following are two use cases for creating a set master rule to select the master record based on D-U-N-S number, number of party sites, and party ID:

Use Case 1

In this case, there are three records with D-U-N-S number and two records with highest number of party sites. Among those two records, the one with the lower value for party ID is selected as master. The following table contains the sample record information for this use case.

Record Name Party ID Number of Party Sites D-U-N-S Number Master

Record 1

11

3

198837472

Yes

Record 2

12

3

489203901

No

Record 3

13

2

384792392

No

Record 4

14

1

null

No

Use Case 2

In this case, there are no records with D-U-N-S number. So, among the two records with higher number of party sites, the record with the smaller party ID is picked as the master record. The following table contains the sample record information for this use case.

Record Name Party ID Number of Party Sites D-U-N-S Number Master

Record 1

21

1

null

No

Record 2

22

2

null

Yes

Record 3

23

3

null

No

To create a master record with D-U-N-S number, number of party sites, and party ID, you add one more condition to the previous example where you set a master record with D-U-N-S number. Adding a condition to the previous example makes the rules complicated and cumbersome. Instead, you can create a simple rule for each condition to narrow down the list of potential master records and create another simple rule in the end to pick one record from the remaining potential master records.

Note: You can activate more than one survivorship rule at a time. When you activate multiple rules, make sure that the rules aren't conflicting and the conditions in the rule are set according to the priority.

The following figure displays the Survivorship Rules: Select Master Record page with the IF and THEN rules condition values for creating a set master rule to set the record that has D-U-N-S Number as master. The priority of the rule is set as highest. The details of the conditions are as follows:

Priority: Highest

IF condition: If number of non-null DUNS records is the count where {master is a HZ_ORGANIZATION_FactType.OrganizationPartyVO and master.DUNSNumberC isn't null} and number of non-null DUNS records more than 0 and master is a HZ_ORGANIZATION_FactType.OrganizationPartyVO and master.DUNSNumberC is null

THEN condition: Then retract master

The Survivorship Rules: Select Master Record page
with the IF and THEN rules condition values to set the record that
has D-U-N-S Number as master.

Now, you set the conditions to set the record with the maximum number of party sites as the master.

The following figure shows the Survivorship Rules: Select Master Record page with the IF and THEN condition values to set the record with the maximum number of party sites as the master from the remaining potential records. The priority of the rule is set as higher. The details of the conditions are as follows.

Priority: Higher

IF condition: If maximum party site number is the maximum of master.PartySite.size() where {master is a HZ_ORGANIZATION_FactType.OrganizationPartyVO} and master is a HZ_ORGANIZATION_FactType.OrganizationPartyVO and master.PartySite.size() isn't maximum party site number

THEN condition: Then retract master

The Survivorship Rules: Select Master Record page
with the IF and THEN rules condition values to set the record that
has more party sites as master.

When the records are screened with two previous conditions, you create a third condition to screen all remaining potential records with the smallest party ID.

The following figure shows the Survivorship Rules: Select Master Record page with the IF and THEN condition values for creating a set master rule to set the record with the smallest party ID as the master. The priority of the rule is set as medium. The details of the conditions are as follows.

Priority: Medium

IF condition: If masterPartyId is the minimum of master.PartyId where {master is a HZ_ORGANIZATION_FactType.OrganizationPartyVO}

THEN condition: Assert new Result(name: "masterId",value:masterPartyId)

The Survivorship Rules: Select Master Record page
with the IF and THEN rules condition to set the record with the smallest
party ID as the master. This condition is picked only if the first
two conditions aren't met.

In this example, the rules are created to narrow down the list of potential master records. When you activate more than one rule at a time you should set the conditions for the rule according to the priority to narrow down the list of potential master records. In this example Eliminate Null D-U-N-S Number rule is executed first to select records with D-U-N-S Number. Select the Most Address rule is executed next to find the master record with most number of party sites among the potential master records having D-U-N-S Number. Finally, Select Minimum Party ID rule is executed at the end to pick the minimum party ID from the remaining party records.

This example demonstrates how to create a survivorship rule of the type Set Attribute Value. You can determine survivorship at the attribute level using the set attribute value survivorship rule type. Set attribute value rules are used in party merge to determine which attribute value should come from which record.

The input to the survivorship rule is given in the IF clause. In a set attribute value rule, the inputs are the party records and their source information. The source information contains information about all attributes for each record in the database. If you're creating rules that use the Source information VO, you define it in the Define Source Systems Confidence page of the Manage Source System Confidence task. You must map each attribute to its source system and given a Source Confidence score on a scale of 1 to 100.

The following table lists the attributes in the source information VO to create a set attribute value rule.

Attribute Name Description

RecordId

The record ID of a specific attribute.

AttributeName

The name of the attribute.

Source

The source system from where the attribute is updated.

SourceConfidenceLevel

The source confidence level assigned to the source system.

SourceUpdateDate

The date when the attribute was last updated.

The THEN clause determines the output object that picks the survivor record. In this case, setAttribute function creates the output object. To create Set Attribute Value rules, you perform the following steps:

  1. Navigate to the Manage Survivorship Rules task.

  2. Click Add. The Create Survivorship Rule page appears.

    Tip: You can select attributes from the available attributes in the Create Survivorship Rule page. It pre-populates the rule template with the selected attributes. It's not mandatory to set attributes from the available attribute.
  3. Enter the sample information provided in the following table on the Create Survivorship Rule page.

    Field Value

    Rule Name

    PickAttributeValueRule

    Description

    Select the survivor value for a specific attribute based on specified survivor selection criteria.

    Select the survivor value for a specific attribute based on specified survivor selection criteria.

    Set attribute value

    Object Type

    Organization

    Template

    Select the Attribute Based template to select the surviving value based on the characteristic of the attributes. For example, you need an Attribute Based template to pick an attribute with the highest or lowest value such as a party number, or salary, or the earliest incorporated year. Select the Source Confidence Based template to select the surviving value based on the confidence in the source information.

  4. Select attributes from the available attributes to pre-populate the rules template. In case you want to use the predefined set attribute rules, don't select any attributes.

  5. Click Apply. You're taken to the Define Survivorship Rules: Select Attribute Value page.

In the Define Survivorship Rules: Select Attribute Value page, you specify criteria for selecting the survivor attribute value. The criteria that you define in this page determine the feature of the rule. You also have the option of using one of the following three predefined templates:

  • Highest Source Confidence Level Wins for Organization (or Person): Use this rule to select the attribute values with the highest source confidence level.

  • Most recently updated Organization (or person) attribute: Use this rule to select the attribute values with the most recently updated date.

  • Least recently updated Organization (or person) attribute: Use this rule to select the attribute values with the oldest updated date.

The following sections of this topic contain three worked examples that show different ways of manually setting survivor attribute values in the Define Survivorship Rules: Select Attribute Value page. They are as follows:

  • Set the Values with the Earliest Update Date as the Surviving Attribute Values

  • Set the Value with the Highest Source Confidence Level as the Surviving Attribute Value for D-U-N-S Number

  • Set the Values with the Earliest Incorporated Year as the Surviving Attribute Values

How You Set the Values with the Earliest Update Date as Surviving Attribute Values

This rule has a single condition to set all the surviving attribute values based on the earliest update date. The following is a use case for a set attribute rule to select the values with the earliest update date as surviving attribute values:

Use Case 1

Party Record

The following table contains information for party records.

Record Name Party ID Party Name D-U-N-S Number

Record 1

1

Oracle Corp

198837472

Record 2

2

Oracle USA Corp

489203901

Record 3

3

Oracle

null

Source Information

The following table contains information for source information records.

Record ID Attribute Name Source Source Confidence Level Source Update Date

1

Party Name

FUSION

95

1/5/2016

2

Party Name

FUSION

95

1/5/2010

3

Party Name

SIEBEL

90

1/5/2000

1

D-U-N-S Number

DNB

100

2/5/1990

2

D-U-N-S Number

FUSION

95

1/5/2016

In this case:

  • The D-U-N-S number attribute value from the record with ID 1 is selected as survivor because the source information indicates that it has the earliest source update date.

  • The Party Name attribute value from the record with the ID 3 is selected as survivor because the source information indicates that it has the earliest source update date.

Populate the Define Survivorship Rules: Select Attribute Values page with the IF and THEN rules condition values provided in the following table.

Rule Condition Value

IF Condition

IF picked attribute is a AttributeSourceInfoVO
and there is no case where {
Other Attribute == AttributeSourceInfoVO and
there is no case where
Other Attribute is a AttributeSourceInfoVO
Picked Attribute.Attributename is OtherAttributename and
PickedAttribute.RecordId isn't Other Attribute.recordId and
Picked Attribute.SourceUpdateDate more than OtherAttribute.SourceUpdateDate}

THEN Condition

THEN 
call setAttribute (picked attribute.Attributename, Picked Attribute.RecordId)

The following figure displays the Define Survivorship Rules: Select Attribute Values page with the IF and THEN rules conditions to create the set attribute value rule that selects the values with the earliest source update date as the surviving attribute value. The figure provides the following details.

Name of the rule: History Wins

IF condition: If picked attribute is a AttributeSourceInfoVO and there is no case where {Other Attribute is AttributeSourceInfoVO and Picked Attribute.AttributeName is Other Attribute.AttributeName and PickedAttribute.RecordId isn't Other Attribute.RecordId and Picked Attribute.SourceUpdateDate more than Other Attribute.SourceUpdateDate}

THEN condition: Then call setAttribute (Picked Attribute.AttributeName, Picked Attribute.RecordId)

Completely filled Define Survivorship Rules: Select
Attribute Values page. The IF and THEN rules conditions are populated
for creating the set attribute value rule to select the values with
the earliest source update date as the surviving attribute value.
How You Set the Value with the Highest Source System Confidence Level as the Surviving Attribute Value for D-U-N-S Number

This rule has a single condition to select the D-U-N-S number value with the highest source confidence level as the surviving attribute value for the D-U-N-S number attribute. The following is a use case for a set attribute rule to select the D-U-N-S number value with the highest source confidence level as the surviving attribute value:

Use Case

Party Record

The following table contains information for party records.

Record Name Party ID Party Name D-U-N-S Number

Record 1

1

Oracle Corp

198837472

Record 2

2

Oracle USA Corp

489203901

Record 3

3

Oracle

null

In this case, the party record contains three records with the attribute Party Name and two records with D-U-N-S number. These attributes are picked to create the source information. The source information table defined using the attributes from this party record table is as follows:

Source Information

The following table contains information for source information records.

Record ID Attribute Name Source Source Confidence Level Source Update Date

1

Party Name

FUSION

95

1/5/2016

2

Party Name

FUSION

95

1/5/2010

3

Party Name

SIEBEL

90

1/5/2000

1

D-U-N-S Number

DNB

100

2/5/1990

2

D-U-N-S Number

FUSION

95

1/5/2016

In this case, the D-U-N-S attribute value for the record with ID 1 is selected as survivor because the source information indicates that it has the highest source confidence level among all records that have the D-U-N-S Number attribute.

The following figure displays Define Survivorship Rules: Select Attribute Values page with the IF and THEN rules condition values to set the attribute value with the highest source system confidence level as the survivor. The figure provides the following details.

Name of the rule: Highest Source Confidence Level

IF condition: If picked attribute is a AttributeSourceInfoVO andPicked Attribute.ArrtibuteName is EnquireDUNSNumberC and there is no case where {Other Attribute is a AttributeSourceInfoVO and Picked Attribute.AttributeName is Other Attribute.AttributeName and Picked Attribute.RecordId isn't Other Attribute.RecordId and Picked Attribute.SourceConfidenceLevel is less than OtherAttribute.SourceConfidenceLevel}

THEN condition: Then call setAttribute (Picked attribute.AttributeName, Picked Attribute.RecordId)

Completely filled Define Survivorship Rules: Select
Attribute Values page. The IF and THEN rules conditions are populated
for creating the set attribute value rule to select the values with
the earliest source update date as the surviving attribute value.
How You Set the Values with the Earliest Incorporated Year as the Surviving Attribute Values

This rule has a single condition to select values with the earliest incorporated year as the surviving attribute values. The following is a use case for creating such a set attribute value rule:

Use Case 1

Party Record

The following table contains information for party records.

Record Name Party ID Party Name Incorporated Year

Record 1

1

Oracle Corp

1980

Record 2

2

Oracle USA Corp

1990

Record 3

3

Oracle

2000

In this case, the party record table contains three records with the attributes Party Name, Party ID, and Incorporated Year. The attribute values for the record with the earliest incorporated year are picked as survivor attribute values.

The following figure displays Define Survivorship Rules: Select Attribute Values page with the IF and THEN rules condition values to set the attribute with the earliest incorporated year as the survivor. The figure provides the following details.

Name of the rule: Selecting the Earliest Incorporated Year

IF condition: If for each case where org is a OrganizationDVO and org.IncorpYear isn't null and there is no case where another org is a OrganizationDVO and org.PartyId isn't another org.PartyId and another org.IncorpYear isn't null and org.IncorpYear.intvalue() is more than another org.incorpyear.intValue()

THEN condition: Then call setAttribute ("IncorpYear", org.PartyId)

Completely filled Define Survivorship Rules: Select
Attribute Values page. The IF and THEN rules conditions are populated
for creating the set attribute value rule to select the values with
the earliest source update date as the surviving attribute value.

Survivorship Rules for Parties with Custom Objects and Attributes

This topic describes how to define survivorship rules for merging parties having custom objects and attributes. For example, you can define a survivorship rule of the type Set Master Record to select the party with the maximum number of custom objects or the party with a specific attribute as the master. You can also define a survivorship rule of the type Set Attribute Value to select the smallest value for a specific attribute.

Custom Objects and Attributes

You can use Oracle Application Composer to configure and extend Oracle CX Sales and B2B Service applications. The Application composer provides you the ability to extend an Oracle CX Sales and B2B Service application's object model. You can configure CX Sales and B2B Service objects by adding new fields (custom fields or custom attributes) to an existing object (standard objects). Or you create entirely new objects (custom objects) and related fields (custom attributes).

Custom Objects and Attributes in Survivorship Rules

The following table describes the basic merge operations that can be performed on standard or custom objects.

Object Examples Can be merged Can be transferred Can be removed

Standard Top-Level Object

Account/Organization

Contact/Person

Yes

Not applicable for top-level objects

Not applicable for top-level objects

Standard Child Object

Address

Phone

Yes (by reviewing in the Data Steward UI)

Yes (by default if not merged or removed)

Yes (by reviewing in the Data Steward UI)

Standard Child Object

Lead

Opportunity

No

Yes (always)

No

Custom Top-Level Object

Not applicable (implementation specific)

No

Not applicable for top-level objects

Not applicable for top-level object

Custom Child Object

Not applicable (implementation specific)

No

Yes (always)

No

The following table describes whether or not these objects and attributes can be used while defining conditions, clauses, and actions for survivorship rules of the type Set Master Record and Set Attribute Value.

Object Examples Can be used in Set Master Record rule conditions Can be used in Set Master Record rule actions Can be used in Set Attribute Value rule conditions Can be used in Set Attribute Value rule actions Can be used for Attribute Override in Data Steward UI

Standard Top-Level Object

Account/Organization

Contact/Person

Yes (standard and custom attributes)

Yes (standard record ID attribute)

Yes (standard and custom attributes)

Yes (standard and custom attributes)

Yes (standard and custom attributes)

Standard Child Object

Address

Phone

Yes (standard and custom attributes)

No, survivorship not supported for child objects

No, survivorship not supported for child objects

No, survivorship not supported for child objects

No, attribute override not supported for child objects

Standard Child Object

Lead

Opportunity

Yes (standard and custom attributes)

Not applicable if you can't merge the records

No

Not applicable if you can't merge the records

Not applicable if you can't merge the records

Custom Top-Level Object

Not applicable (implementation specific)

No

Not applicable if you can't merge the records

No

Not applicable if you can't merge the records

Not applicable if you can't merge the records

Custom Child Object

Not applicable (implementation specific)

Yes (all attributes are custom)

Not applicable if you can't merge the records

No

Not applicable if you can't merge the records

Not applicable if you can't merge the records

This topic explains how to define a survivorship rule of the type Set Master Record to select the party with the maximum number of custom child objects.

This rule identifies and returns the master record based on the following two conditions:

  1. Pick master that has the most custom child objects.

  2. Pick master that has the highest party ID.

The following table provides the details of a use case for set master record rule to select the party with the maximum number of custom child objects and the highest party ID as the master record.

Record Number Party ID Number of Custom Child Objects Master

Record 1

11

3

No

Record 2

12

3

Yes

Record 3

13

3

No

Record 4

14

1

No

In this case, there are two records with the same number of custom child objects. Therefore, the record with the highest party ID is picked up as the master record.

Note: The number of child objects of the custom object is shown up as Fact Types. You can also find out the number of child objects using the accessor inside OrganizationDVO or PersonDVO.

The following figure displays Define Survivorship Rules: Select Master Record page with the IF and THEN rules condition values for creating the set master rule to pick up the record with the highest party ID and maximum custom child objects as the master record.

Define Survivorship Rules: Select Master Record
page with the IF and THEN rules condition values to create the set
master rule.

This topic explains how to define a survivorship rule of the type Set Master Record to select the party with a specific custom attribute as the master.

This rule identifies and returns the master record based on the following two conditions:

  1. Pick master that has a specified custom attribute. In this case the custom attribute is Testfieldone_c.

  2. Pick master that has the highest Party ID.

The following table provides the details of a use case for setting master record rule to select the party with a specific custom attribute as the master.

Record Number Party ID Testfieldone_c Master

Record 1

11

Test

No

Record 2

12

Test

Yes

Record 3

13

None

No

Record 4

14

None

No

In this case, there are two records with the custom attribute Testfieldone_c. Therefore, the record with highest party ID is picked as the master record.

The following figure displays Define Survivorship Rules: Select Master Record page with the IF and THEN rules condition values to create the set master record rule to pick the record with specified attributes as the master. The details of the conditions are as follows:

IF condition: If masterPartyId is the maximum of master.PartyId where {master is a HZ_PERSON_FactType.PersonDVO and master.Testfielddone_c isn't null}

THEN condition: Then Assert new Result (name:"masterId", value:masterPartyId)

Define Survivorship Rules: Select Master Record
page with the IF and THEN rules condition values to create the set
master record rule

This topic explains how to define a survivorship rule of the type Set Attribute Value to select the smallest value for a specific attribute. This rule has a single condition where it picks a record that has the smallest value for the specified custom attribute.

The following table contains the details of a use case for a set attribute value rule to select the smallest value for a specific custom attribute as the survivor. In this case the example attribute name is CustomField1_c.

Record Number Party ID CustomField1_c Attribute Value Party Name Survivor

Record 1

11

123

Oracle Corp

Yes

Record 2

12

1456

Oracle USA Corp

No

Record 3

13

239940

Oracle

No

In this case, there are three records with CustomField1_c custom attribute. The value 123 is picked up as the survivor value for the CustomField1_c custom attribute because it's the smallest value for that attribute.

The following figure displays the Define Survivorship Rules: Select Attribute Value page with the IF and THEN rules condition values to create the set attribute value rule to pick the smallest value for the CustomField1_c custom attribute as the survivor. The details of the conditions are as follows:

IF condition: If (for each case where) {org is a OrganizationDVO and org.CustomField1_c isn't null } and there is no case where {another org is a OrganizationDVO and another org.CustomField1_c isn't null and org.PartyId isn't another org.PartyId and org.CustomField1_c.length() more than another org.CustomField1_c.length()}

THEN condition: Then call setAttribute("CustomField1_c", org.PartyId)

Define Survivorship Rules: Select Attribute Value
page with the IF and THEN rules condition values for creating the
set attribute value rule to pick the smallest value for the CustomField1_c
custom attribute as the survivor

What's the difference between survivorship rules and merge agreement rules?

Survivorship rules are a collection of business rules defined for the creation of the best version record intelligently, especially from multiple source systems, by specifying criteria for selecting record and attributes to be retained during merge or link operations.

A merge agreement rule is a collection of patterns and conditions that are defined to determine whether a merge request should be vetoed by the application or not. Merge requests that violate these rules are either rejected or end in error.

How can I check if the survivorship rules that I created work?

You can create two parties and merge them into a single record to check if your survivorship rules are working. You must ensure that your survivorship rules are active before merging the parties.

What are the seeded sample survivorship rules that Oracle Fusion Applications provide by default?

Oracle Fusion Applications offer the following sample survivorship rules:

  • For organizations, history wins: The attribute value with earlier source update date wins. This rule is applicable for all organization attributes.

  • For persons, recent wins: The attribute value with later source update date wins. This rule is applicable for all person attributes

  • For organizations, assign the highest source confidence level to the D-U-N-S number.

The seeded survivorship rules are in inactive status out-of-the-box. These rules are updated with every release. However, once you change these rules, these rules aren't updated.

Agreement Rules

An agreement rule is a collection of patterns and conditions that are defined to determine whether a merge request should be vetoed by the application or not. Merge requests that violate these rules are either rejected or end in error.

Agreement rules let you check a merge request for any veto conditions that can prevent a merge from occurring. These rules save resources and time by obviating the need to review merge requests to prevent undesired merge from being processed. Besides, agreement rules prompt you to consider alternative duplicate resolution mechanism such as linking.

Agreement rule can be of the following two types:

  • Predefined

  • User-defined

Predefined Agreement Rules

These are agreement rules that are predefined in the application. You can only view the predefined agreement rules.

The following table describes the predefined agreement rules shipped out of the box with the application. Merge requests that violate these rules are automatically rejected.

Name Description

HR_APPLICANT_VETO

Prevents a person party with an active party usage of HR_APPLICANT from merging with another party.

HR_EMPLOYEE_VETO

Prevents a person party with an active party usage of HR_EMPLOYEE from merging with another party.

HR_CONTINGENT_WORKER_VETO

Prevents a person party with an active party usage of HR_CONTINGENT_WORKER from merging with another party.

HR_PARTY_SITE_VETO

Prevents a party site with active original system reference from Oracle Fusion Human Capital Management system from merging with another party site.

RESOURCE_PERSON_VETO

Prevents a person party with an active party usage of RESOURCE from merging with another party.

BANK VETO

Prevents an organization party with an active party usage of BANK from merging with another party.

CLEARINGHOUSE_VETO

Prevents an organization party with an active party usage of CLEARINGHOUSE from merging with another party.

BANK_BRANCH_VETO

Prevents an organization party with an active party usage of BANK_BRANCH from merging with another party.

BRANCH_CLEARINGHOUSE_VETO

Prevents an organization party with an active party usage of CLEARINGHOUSE_BRANCH from merging with another party.

LEGAL_EXTLEGAL_PARTYUSGRULE_VETO

Prevents an organization party with active party usage of LEGAL_ENTITY from merging with another organization party with active party usage of EXTERNAL_LEGAL_ENTITY.

IC_PARTICIPANT_PERSON_VETO

Prevents a person party with an active party usage of INCENTIVE_COMP_PARTICIPANT from merging with another party.

IC_PARTICIPANT_ORG_VETO

Prevents an organization party with an active party usage of INCENTIVE_COMP_PARTICIPANT from merging with another party.

PARTNER_VETO

Prevents an organization party with an active party usage of PARTNER from merging with another party.

INACTIVE_PARTNER_VETO

Prevents an organization party with an active party usage of INACTIVE_PARTNER from merging with another party.

CUST_CONTACT_DIFF_RESOURCE_ORG_VETO

Prevents two partner owned contacts belonging to different resource organizations from being merged.

CUST_CONTACT_INTERNAL_PARTNER_VETO

Prevents a partner owned contact that doesn't belong to a resource organization from merging with another partner owned contact that belongs to a resource organization.

CUST_CONTACT_INTERNAL_PARTNER_ORG_VETO

Prevents a contact owned by an internal user from merging with a contact owned by a partner user.

CARD_ISSUER_VETO

Prevents an organization party with an active party usage of CREDIT_CARD_PROVIDER from merging with another party.

LEGAL_ENTITY_VETO

Prevents an organization party with an active party usage of LEGAL_ENTITY from merging with another party.

ESTABLISHMENT_VETO

Prevents an organization party with an active party usage of ESTABLISHMENT from merging with another party.

HIERARCHY_CYCLE_PREVENTATION_VETO

Prevents merge from happening when the master party record is at a level lower than the nonmaster party record within the same active tree version.

NAMEDACCOUNT_UNNAMEDACCOUNT_VETO

Prevents merge from happening when the master party record isn't a named account whereas the nonmaster party recordis a named account and these are in active hierarchies.

User-defined Agreement Rules

These are additional agreement rules that you can define to determine whether a merge request should be vetoed by the application. You can create, view, update, and delete user-defined agreement rules.

Note: The application doesn't support changing agreement rules inside the Application Composer sandbox. Therefore, the merge engine doesn't pickup the changes made to these rules inside the Application Composer sandbox.

An agreements rules dictionary is a collection of predefined terms and attributes that can be used to define agreement rules. The Oracle Customer Data Hub comes with a single predefined dictionary (HZ_Parties) that contains all the predefined Agreement Rules shipped out of the box with the application. You can also use this dictionary to define custom agreement rules according to your business requirements. Note that you can only view the predefined agreement rules. You can't edit them. In contrast, you can create, view, update, and delete user-defined agreement rules. Merge requests that violate agreement rules are rejected.

Before using this dictionary to define custom agreement rules, you must review whether the agreement rule terms and term attributes existing in the predefined agreement rules dictionary are sufficient to define custom agreement rules needed to meet your business requirements. If required, refresh terms to import the latest terms, term attributes, and related metadata, for example, fact types such as entities and objects. Refreshing the dictionary help you pull in all the newly added custom attributes for accounts and contacts.

This example demonstrates how to create user-defined agreement rules that you can use to prevent a merge request from being processed.

Agreement rules are collections of patterns and conditions that are defined to determine whether a merge request should be vetoed by the application or not. Perform the following tasks to define agreement rules:

  • Review and refresh terms in the predefined agreement rules dictionary shipped out of the box

  • Add a new agreement rule

For more information on agreement rules, see Oracle Fusion Middleware User's Guide for Oracle Business Rules on Oracle Technology Network at http://www.oracle.com/technetwork.

Review and Refresh Terms in the Predefined Agreement Rules Dictionary

The Customer Hub application is shipped with a predefined agreement rules dictionary that contains all the predefined Agreement Rules shipped out of the box with the application. Before using this dictionary to define custom agreement rules, you must review whether the agreement rule terms and term attributes existing in the predefined agreement rules dictionary are sufficient to define custom agreement rules needed to meet your business requirements. If required, refresh terms to import the latest terms, term attributes, and related metadata, for example, fact types such as entities and objects. Refreshing the dictionary helps you pull in all the newly added custom attributes for accounts and contacts. Use the following steps to review and refresh the agreement rules dictionary:

  1. In the Setup and Maintenance work area, go to the following:

    • Offering: Customer Data Management

    • Functional Area: Customer Hub

    • Task: Manage Agreement Rules

  2. On the Manage Agreement Rules page, review whether the agreement rule terms and term attributes existing in the predefined agreement rules dictionary are sufficient to define custom agreement rules needed to meet your business requirements.

  3. Click Refresh Terms to import the latest terms, term attributes, and related metadata.

  4. Click OK in response to the confirmation message.

Add a New Agreement Rule
After reviewing and refreshing the Agreement Rules Dictionary using the earlier steps, perform the following steps to create a new custom agreement rule:
  1. On the Manage Agreement Rules page, click Next to navigate to the Manage Agreement Rules: Define Rules page.

  2. Click Add form the Actions menu to add a new rule.

  3. Enter a rule name.

  4. Click Define Rule.

  5. Enter the reason for creating the agreement rule in the Justification Reason.

  6. Click Add form the Actions menu to create a new pattern.

  7. Complete the fields in the new pattern field using the sample information provided in the following table. Use the default values except where indicated. Note that the relation is always AND between patterns and can't be edited. You must include the Dictionary Terms OrganizationPartyVO and PersonPartyVO, with defined MergeType, into the Define Patterns column. These patterns determines the master and nonmaster records.

    Pattern Dictionary Term Term Alias Relation

    for each case where

    PersonPartyVO

    Person

    AND

    for each case where

    OrganizationPartyVO

    NonmasterParty

    AND

    there is a case where

    PartyUsageAssignmentVO

    PartyUsageAssignment

    AND

  8. Navigate to the Conditions table.

  9. Click Add from the Actions menu to add a new condition and complete the fields using the sample information provided in the following table. Use the default values except where indicated.

    Term Attribute Operator Value Relation

    Person.PartyNumber

    is not

    1234

    AND

    NonmasterParty.MergeType

    =

    Nonmaster

    AND

    UsageAssignment.PartyUsageCode

    =

    HR_APPLICANT

    AND

  10. Click Save or Save and Close.

  11. Click Submit.

Source System Confidence

Source system confidence levels indicate the reliability of a particular source system for specific attributes. They are used to determine the master or surviving record among multiple duplicate records from different source systems.

For each source system, you can set source confidence score for attributes in the Person and Organization objects. The scores are used to select attributes for the master record during merge operation. The scores are used to select attributes, based on the survivorship rules, for the master record during merge operation. You assign source confidence levels based on your understanding of the quality of the data stored in the various source systems within your organization.

Source system confidence levels range from 0 to 100.

You can use source system confidence levels for creating survivorship rules. Survivorship rules are used to retain master records during merge, insert, or update operations.

Source system confidence levels

You can import data from legacy or source systems into the application. The legacy or source systems usually store data associated with the same attributes across systems. Similarly, multiple source systems may have data related to the same account.

Source system confidence levels let you indicate how much you trust the data from a specific source system for an attribute. For example, you may trust the customer address data coming from a financial system more than the same data from a marketing system. Similarly, you may trust the employee name data coming from the Human Relationships system more than the same data coming from the Marketing system. While specifying source system confidence levels, you must ensure that only the most reliable data is selected as the master data.

Survivorship rules

Oracle CX Sales and B2B Service uses a central data model updated by authorized users from multiple applications. Often, different applications or source systems update the same data resulting in a data conflict.

Survivorship rules are custom business rules that determine how conflicts should be automatically resolved while merging or updating duplicate records from different source systems or applications. For example, you can create a survivorship rule to select the latest customer address data when there are duplicate records.

Relationship between source system confidence levels and survivorship rules

Source system confidence levels enable you to build your survivorship rules to resolve duplicate data associated with specific attributes. For example, you could create survivorship rules to:

  • Select the record from a source system with confidence values of 80 and above as the master record.

  • Automatically reject records from source systems with confidence values of 30 and below.

FAQs for Source System Confidence

What are Set Master and Set Attribute rules?

Set Master rules enable you to define the logical business criteria for selecting the master record from a set of potential duplicate records for merge operations.

Set Attribute rules enable you to define the logical business criteria for selecting the best attribute values from multiple input records during merge operation.

Yes, you can apply the same source system confidence level to multiple attributes of an object type. You can manage source system confidence levels using the following in the Setup and Maintenance work area: offering: Customer Data Management; functional area: Customer Hub; task: Manage Source System Confidence.

The automerge functionality merges duplicate records without any approval or intervention from the data steward. Automatic processing of merge requests is critical when processing large volumes of customer data as automerge can expedite the resolution of duplicate records without manual review. During automerge, the child entities of the duplicate records, such as contact points, relationships, classifications, and cross references, become the child entities of the master record. Note that groovy scripts on relationship objects don't run during merges. If they're critical, you can re-implement the scripts on the parent account or contact.

How Records are Selected for Automerge

Records are selected for automerge based on the following criteria:

  • Score threshold: The score threshold is defined in the Match Configuration and determines if a record is included in a duplicate set.

  • Automerge threshold: The automerge threshold is defined by the ZCH_AUTO_MERGE_THRESHOLD profile option and determines if the merge request for a duplicate set is processed automatically or if it must be reviewed manually.

Three possible outcomes for each record with regard to duplicate identification and merging are as follows:

  • Low score below score threshold: The record isn't included in duplicate set and in the merge request for that duplicate set.

  • Medium score above score threshold and below automerge threshold: The record is included in duplicate set but merge request for that duplicate set must be reviewed manually.

  • High score above score threshold and above automerge threshold: The record is included in duplicate set and merge request is processed automatically.

The score for all the records in a duplicate set must be above the automerge threshold for automated processing. If one record in the duplicate set is below automerge threshold, and the other records are above the automerge threshold, the merge request must be reviewed manually.

Note: When you merge two or more records with exactly same children information under phone, email, or address the children information is merged and rolled up to the survivor record.

How You Configure Automerge

Enabling Automerge involves several implementation steps that must be completed by an implementor using the following tasks from the Customer Data Management offering in the Setup and Maintenance work area:

  • Manage Customer Hub Profile Options: Use this task from the Customer Hub functional area to perform the following implementation steps:

    • Set Auto Merge Threshold profile option (ZCH_AUTO_MERGE_THRESHOLD) to the required value. This profile option specifies the threshold for auto merge. Merge requests with lower scores need data steward review. An exact match is 100.

    • Review the Record Size Limit of Duplicate Set (ZCH_DI_MERGEREQ_REC_SIZE). This profile option determines the maximum number of records in the duplicate set that can be merged automatically. By default, the maximum number is set to 10 records.

    • Set the Survivorship Enabled profile option (ZCH_ENABLE_SURVIVORSHIP) to Yes. This profile option enables the survivorship rules to select the master record and retain the attributes during a merge operation.

  • Manage Survivorship Rules: Use this task from the Customer Hub functional area to create Set Master survivorship rules to choose the master record for merge requests created from the duplicate identification batch and set the rule to active.

    If there are no active Set Master rules or if the Set Master rules didn't trigger, the merge request must be reviewed manually, even if the ZCH_AUTO_MERGE_THRESHOLD profile option is set, the score for all records is above the threshold value, and the number of records is below the record size limit.

    Note: You can use the Set Attribute rules with Set Master rules to determine the Golden Master record. For automerge, Set Master rule is mandatory.
  • Manage Enterprise Data Quality Matching Configurations: Use this task from the Data Quality Foundation functional area to perform the following implementation steps:

    • Create an active Match Configuration in Manage Enterprise Data Quality Matching Configurations task or use a predefined Match Configuration. Rebuild the keys if necessary.

    • Enable EDQ Real Time and Batch Basic Match Server in Manage Server Configurations task.

Run Automerge

This task involves the following two steps:

  1. Create a duplicate identification batch and select Create Merge Request as the Automatic Processing Option.

  2. Perform the task Run Request Dispatch Job to disposition the duplicate resolution sets.

The Dispatch Job processes any resolution request in Pending or Submitted status. You can run this job in two modes:

  • On demand: Run Request Dispatch Job > Submit

  • Per a specific schedule: Do the following steps to set up a recurring job:

    1. Click Advanced on the Run Request Dispatch Jobtask.

    2. Click Schedule tab and select the Using a Schedule radio button.

    3. Select the frequency you want and click Submit.

To see the list of dispatch jobs, and their statuses, navigate to Scheduled Processes under Tools.

Troubleshoot Automerge Issues

After you create your Duplicate Identification Batch, drill down into the completed batch to see the results. If duplicate sets have been found, and automerge is enabled, resolution requests are automatically submitted for merge.

If the resolution request wasn't submitted automatically, you can drill down to the duplicate set and compare the score for each record with the threshold in the ZCH_AUTO_MERGE_THRESHOLD profile option and the number of records with the limit in the ZCH_DI_MERGEREQ_REC_SIZE profile option. If all scores are above the threshold and the number of records is below the limit, verify that the following are true:

  • Set Master rules are active and triggered to choose a master for the records in the duplicate set.

  • ZCH_ENABLE_SURVIVORSHIP is set to yes.

High Volume Batch Deduplication

Batch deduplication of account or contact records in Oracle Customer Data Management Cloud Service consists of the following two steps:

  • Duplicate Identification: This step includes the identification of duplicate records by submitting a Duplicate Identification Batch job.

    You can define and submit this job from the Duplicate Identification page.

  • Duplicate Resolution: This step includes the resolution of the duplicates, typically by merging each set of duplicate records.

    You can resolve the duplicates either automatically by submitting the Duplicate Identification Batch job (called Automerge) or manually by submitting records in bulk from the Duplicate Identification Batch results review page.

For more details on these steps and for configuration of Automerge, see Merge Requests, Implementing Customer Data Management.

Both of these jobs are data-intensive operations that can read or update millions of rows of data in various Oracle Application Cloud tables. This document is intended to provide the guidelines and best practices for planning the data-sets, and applying appropriate configurations to achieve optimal throughput for high volume deduplication in Oracle Customer Data Management Cloud Service. Each customer's data set is unique. The time required to process a duplicate identification batch varies on the data shape.

Best Practices for High Volume Batch Deduplication

Customer Data Management merge is a data-intensive process that scans and updates a large number of tables in Oracle Applications Cloud, to correctly merge two or more Accounts or Contacts.

This section describes how you can use the following profile options to optimize the merge process:

  • Scope of Merge Process (ORA_ZCH_MERGE_SCOPE): You can use this profile option to define the scope of the merge process.

  • Master Record Selection Method (ORA_ZCH_SETMASTER): You can use this profile option to specify the method for selecting the master record in a merge request.

  • Create Automerge with Review (ORA_ZCH_AUTOMERGE_REVIEW): You can use the profile option to select an appropriate processing option for Automerge.

  • Maximum Number of Concurrent Merge Jobs (ORA_ZCH_MERGE_MAX_REQUEST_LIMIT): Specify the maximum number of merge jobs to be processed at a time. If you don't set the maximum limit, all merge jobs are submitted for concurrent processing.

You can set these profile options in the Setup and Maintenance work area using the following:

  • Offering: Customer Data Management

  • Functional Area: Customer Hub

  • Task: Manage Customer Hub Profile Options

How You Define the Scope of the Merge Process

When you merge two or more records, the application scans hundreds of transactional and reference tables across all modules in the Oracle Applications Cloud such as, Core Customer Data Management, CRM, Financials, and Manufacturing. This can make merge a data-intensive and time consuming process. However, you can use the Scope of Merge Process (ORA_ZCH_MERGE_SCOPE) profile option to define and limit the scope of merge process in an implementation so that the application scans only the necessary business areas. This optimizes the size of the merge memory and execution profile.

The following options are supported by the Scope of Merge Process profile option:

  • All Functional Areas (ALL): This is the default option and scans across all areas of Oracle Applications Cloud. You use this option when there's a global implementation running various modules of Oracle Applications Cloud such as, Core Customer Data Management, CRM, Financials, and Manufacturing.

  • All Customer Relationship Management Related Areas (CRM): This option limits the scope of the process to handle all the CRM entities such as, Opportunities, and Leads, core Customer Data, Common Entities such as, Notes, and Activities, and Custom Objects. You use this option when there's a CRM implementation along with the use of Customer Data Management functionality.

  • Customer Data Management Specific Areas: This option limits the scope of the process to core Customer Data, Common Entities such as Notes and Activities, and Custom Objects. You use this option during the initial customer data consolidation and to achieve best performance for Customer Data management, implementations.

Note: The profile option settings can be changed at any time, if additional modules are turned on the instance. For instance, the Customer Data Management option might be used during initial consolidation and cleanup of customer data and then changed to CRM or ALL options if other modules are implemented later.

How You Define the Master Record Selection Method

The performance of the merge process also depends on the method used to select the master record. You can use the Master Record Selection Method (ORA_ZCH_SETMASTER) profile option to specify an appropriate option for selecting the master party automatically during merge. The following options are supported by the Master Record Selection Method profile option:

  • Select master record using survivorship rule (RULE): This is set as the default master selection option. This option selects the master record based on the Set Master rules defined in the Manage Survivorship task. These rules are applied using the Oracle Business Rules component. You use this option when there are complex business rules required to pick the master.

  • Select the oldest record as master (OLDEST): This option selects the party with the earliest creation date as the master.

  • Select the newest record as master (NEWEST): This option selects the party with the newest creation date as the master.

  • Select master based on duplicate identification results (ANY) - This option randomly selects one of the parties in the set as a master.

How you Configure Automerge Action

Automerge is the process of automatically merging identified duplicate sets that exceed the automerge threshold. The process is initiated by creating a duplicate identification batch with the Create Merge Request option. You can use the Create Automerge with Review (ORA_ZCH_AUTOMERGE_REVIEW) profile option that has Yes and No values to select an appropriate processing option for Automerge:

  • Create merge requests only for duplicate sets exceeding the automerge threshold: To enable this processing option, select No as the value for the Create Automerge with Review (ORA_ZCH_AUTOMERGE_REVIEW) profile option. If you select this option, the application processes duplicate sets as follows:

    • The application preprocesses the duplicate sets exceeding the automerge threshold and merges them into a single job. This option is ideal for processing high volumes of merge requests when the duplicate sets require no review or any further action.

    • Duplicate sets not exceeding the automerge threshold remain in Not Reviewed status in the Duplicate Identification page, from where they can be manually converted to merge requests, or rejected, if needed.

  • Create Merge Requests for all duplicate sets: To enable this processing option, select Yes as the value for the Create Automerge with Review (ORA_ZCH_AUTOMERGE_REVIEW) profile option. If you select this option, merge requests are created for all duplicate sets. All requests are first pre-processed. Then they're either merged (if they exceed the automerge threshold), or put in "New" status (so that they can be reviewed) if they don't exceed automerge threshold.

How you Control the Concurrency of Merge Processes

Each merge request executes as a single batch process in the Enterprise Service Scheduler (ESS). The number of merge requests executing concurrently is limited by the number of batches being concurrently processed. Therefore, if there are other ESS processes competing for threads when there are a large number of merge requests queued up, then the scheduling of those jobs could get delayed.

During initial consolidation of customer data, it's advantageous to use the maximum available threads. However, in steady state when there are other processes running in the background, it may be necessary to limit and control the number of concurrent merge ESS jobs.

To achieve this, set the following profile option to an appropriate value:

  • Profile Option Name: Maximum Number of Concurrent Merge Jobs

  • Profile Option Code: ORA_ZCH_MERGE_MAX_REQUEST_LIMIT

    • When the profile option value is left blank or when no value is defined, the ESS will allocate merge requests according to the threads available. This is recommended during initial high volume data processing.

    • After initial data load, set the profile option value to ten or lower if other processes such as Web services or other ESS jobs are running.