Configuring Merge Golden Record Match Action Handlers

The match action configuration includes handlers which are invoked at specific times during processing.

Note: These handlers are optional and may not be needed in all solutions.

For all handlers, the supplied golden records are retrieved by the STEP manager with the context and workspace defined by the matching algorithm. Even if the Approved workspace is selected, the Main workspace is used since changes are not allowed in the Approved workspace.

Create Handler

Any business action added as a Create Handler is run on the golden record after it has been created but before survivorship rules run. This action is only called when a new golden record is created, not when the source record is merged into an identified existing golden record. For more information, refer to the Match and Merge Flow Details topic here.

  • Input: The newly created golden record is bound to the 'Current Object' parameter. Refer to the Current Object Bind topic in the online help Resource Materials documentation here.

Merge Handlers

When merging golden records, the Merge Handler and the Merge Keep First Handler are available.

In Match and Merge, existing golden records can be merged as follows:

  • Automatically - After an update, if the Event Processor detects that two records match each other with a score above the auto-merge threshold.

  • Manually - When the records are in clerical review. This requires a user take the merge action from the Clerical Review Task List or Advanced Merge screen.

For more detail on the flow of these merges, refer to the Match and Merge Flow Details topic here.

While the flows are very similar, the following scenarios differ slightly:

  • When the user of Advanced Merge manually selects the surviving record, the Merge Keep First Handler is entirely skipped.

  • When loading the Advanced Merge screen, the full merge procedure runs, including a call into the handlers. The result is not saved but is used to populate the screen. As a consequence, the Merge Handler should not make calls to external systems.

Merge Keep First Handler

This business condition is called to determine which record will be the survivor. If no Merge Keep First Handler is provided, the oldest record in STEP survives.

  • Input 1: One golden record is bound to the 'Current Object' parameter. Refer to the Current Object Bind topic in the online help Resource Materials documentation here.

  • Input 2: Another golden record to be deactivated / deleted is bound to the 'Secondary Object' parameter. Refer to the Secondary Object Bind topic in the online help Resource Materials documentation here.

  • Output: True if the Golden Record bound to the Current Object should survive; false if the object bound to Secondary Object Bind should survive.

Merge Handler

This business action is called when the survivorship rules have merged the information of the two entities, but before the non-surviving entity is deactivated.

  • Input 1: The newly updated survivor golden record is bound to the 'Current Object' parameter. Refer to the Current Object Bind topic in the online help Resource Materials documentation here.

  • Input 2: The golden record to be deactivated / deleted is bound to the 'Secondary Object' parameter. Refer to the Secondary Object Bind topic in the online help Resource Materials documentation here.

Note: The Merge Handler is designed to make updates on the survivor. It should not be used to call external systems. When loading the Advanced Merge screen, the Merge Handler is called, but the user may cancel the merge. This is handled by STEP by not committing the change made to the survivor by the Merge Handler.