Need

In some migration or integration scenarios, a business identifier must remain stable over time, even when golden record clusters evolve.


A common example is a customer migrating from one MDM platform or database technology to another while preserving an existing business identifier consumed by downstream systems.

During the migration:

  • Existing records may already have a historical business identifier.
  • New records may require a newly generated identifier.
  • The identifier must remain stable after matching, merging, or survivorship changes.

One approach is to:

  • Use a pre-consolidation enricher to retrieve and preserve historical identifiers.
  • Use a post-consolidation enricher to generate a new identifier when none exists.

However, a challenge arises because values generated during post-consolidation are not automatically persisted back into the SD or MI tables. As a result, future integrations may not be able to reuse the generated identifier and may recalculate it, causing instability.


Summarized Solution

When a business identifier is generated during the post-consolidation phase, it cannot be directly written back into the MI table using standard certification processing.


Because of the certification workflow order:

  • A post-consolidation enricher can generate a value in the golden record.
  • That value is not available to earlier stages of the certification process.
  • A lookup enricher cannot retrieve a value that has not yet been generated.

To persist and reuse the generated identifier, the recommended options are:

  • Populate the identifier during migration whenever possible.
  • Use a custom stored procedure or database logic to write the generated value back to the desired table.
  • Optionally reprocess records after persisting the identifier.

The appropriate approach depends on the migration strategy and operational constraints.


Detailed Solution

Understanding the Certification Flow

The root cause of the issue lies in the certification process sequence.

In the described use case:

  • Existing Records: a pre-consolidation enricher retrieves the historical identifier > this works because the value already exists and can be reused during certification.
  • New Records: for records that have never been loaded before, a post-consolidation enricher generates a new identifier > this creates the required business identifier at the golden level.


Why a Lookup Enricher Does Not Solve the Problem

A lookup enricher can retrieve values from the MI table and store them elsewhere during certification.

However, in this scenario:

  • The identifier is generated during post-consolidation.
  • The MI table processing occurs earlier in the certification flow.
  • The generated value does not yet exist when MI processing takes place.

Therefore:

  • A lookup enricher can read from MI.
  • A lookup enricher cannot write a post-consolidation value back into MI during the same certification cycle.

In other words, the certification process cannot "go backwards" and update earlier stages once post-consolidation has completed.


Option 1 - Populate the Identifier During Migration

If historical identifiers already exist in the source system, the safest approach is to migrate them directly.

Benefits:

  • No custom development.
  • No additional certification logic.
  • Stable identifiers immediately available.

During migration:

  • Load the identifier as a normal business attribute.
  • Preserve the original value from the source platform.
  • Reuse it during subsequent integrations.

This was identified as the preferred approach for existing records.


Option 2 - Use a Stored Procedure or Custom Database Logic

Another possibility is to implement a stored procedure that:

  • Retrieves the generated identifier.
  • Writes it into the appropriate table.
  • Makes it available for future loads.

Advantage:

  • Can encapsulate business logic.

Considerations:

  • Database-specific implementation.
  • Potential performance impact depending on design.


Option 3 - Reprocess Records

After persisting the generated identifier through a stored procedure, records may be reprocessed to ensure the identifier is available throughout the certification flow.

This approach should be evaluated carefully because reprocessing:

  • Increases integration duration.
  • May trigger additional matching operations.
  • Can introduce complexity if not managed properly.


Best Practice Recommendation

For migration projects:

  • Existing Records
    • Migrate and preserve the historical business identifier directly.
  • New Records
    • Generate the identifier during post-consolidation.
    • Persist it using a stored procedure.
    • Ensure future loads can retrieve the persisted value rather than recalculating it.

This approach minimizes identifier changes and provides stability for downstream systems that depend on the business identifier as a key.