The CopyStorm/Restore Record Lineage feature is specifically designed to maintain data record lineage. It keeps recovery information between different incarnations of the same data within the CopyStorm database, ensuring that the relationship between data at different points in its lifecycle is preserved.

CopyStorm/Restore Record Lineage assists with:

• Ensuring data accuracy. Providing the history of data over its lifetime, you can verify its accuracy and identify potential discrepancies.
• Improving auditability and compliance. Maintaining a record of different versions of data allows you to trace changes made to the data through its full lifecycle.
• Streamlining recovery. Keeping track of all versions of data, even when data recoveries may have changed its unique ID many times, means that you can ensure that data recoveries will not introduce duplicate data.

What is Record Lineage?

Record Lineage refers to the existence of a logical record across one or more physical forms. For example, an ACME Account can exist in both Salesforce Production 1 and Salesforce Production 2. These are logically the same Account, but are represented by two distinct physical records in separate environments.

Lineage is the mechanism by which CopyStorm/Restore tracks and links these physical records back to their single logical identity, enabling comparison & synchronization across systems.

When Does CopyStorm/Restore consider Lineage?

Lineage plays a role in several key stages of the CopyStorm/Restore application:

• Record Insertion
• Record Matching
• Candidate Scanning

Record Insertion

Lineage is created when Lineage Creation is enabled and a record is INSERTED to Salesforce.

Example:

1. Lineage Creation is enabled.
2. ACME Account is inserted into Salesforce
3. CopyStorm/Restore records a new lineage entry for ACME by creating a new row in the CopyForceRecordLineage database table.
   1. Note: Documentation for CopyForceRecordLineage schema can be at the bottom of this article.

The newly inserted ACME Account will have a new Salesforce ID, and is now considered the authoritative (HEAD) revision of the ACME lineage.

There is no limit to the number of records that can exist within a single lineage.

Record Matching

By default, CopyStorm/Restore uses an ID-based record matching policy. However, when considering lineage during restoration, this approach can fall short—because a single logical record may exist in multiple environments with different Salesforce IDs.

To address this, CopyStorm/Restore examines the lineage of the target record to identify the best match in Salesforce.

The general rule of thumb for Lineage-based matching is:

• The closest valid lineage match in Salesforce will be used as the record match.

Note: When using Multi-Column or External ID matching policies, those methods will take priority. Lineage-based matching will only be used as a fallback if no matches are found through the primary matching policy.

Example Scenario

The user wants to UPDATE the “Phone” field for HEAD ACME in Salesforce with the “Phone” value from an older ACME record.

1. CopyStorm/Restore identifies a legacy (non-HEAD) lineage ACME Account for restoration.
2. The legacy record has a different Salesforce ID than the current HEAD revision.

CopyStorm/Restore will:

1. Retrieve all Lineage information for the legacy ACME record.
2. Search Salesforce for existing lineage entries, starting from the HEAD.
3. Identify the most recent matching record in Salesforce.
   1. In this case, the HEAD exists in Salesforce, so HEAD will be identified as the match.
4. Use that record (HEAD) as the target for the update.

Candidate Scanning

There are three major components to the candidate scanning process:

1. Top Level Candidate Scan
   1. Find all records matching the Record Selector Criteria in the Restore Set Editor
2. Reference Candidate Scan
   1. Find all parent records that are referenced by the results of the top level candidate scan.
3. Related Lists Candidate Scan
   1. Find all child records that reference records in the results of the top level candidate scan.

CopyStorm/Restore provides configuration options to enable/disable Lineage consideration during all phases of the candidate scanning process:

• Enable Record Lineage Candidate Scanning
  • Enables Lineage consideration when scanning top-level candidates.
• Related Lists Scan Options
  • Controls how Lineage is considered when scanning child records.
• Reference Field Scan Options
  • Controls how Lineage is considered when scanning parent records.

Point-In-Time Configuration

When restoring records with lineage enabled, users must specify Point-In-Time configuration parameters to define which version of the record should be restored.

This configuration is determined by the Point-In-Time Strategy selected in the “Recover” drop-down menu.

• Most Recent: Recover the HEAD of lineage.
• A Point In Time: Recover the version of selected records closest to the selected date / time.
• A Single Date: Recover records that were modified on a given date.
• Between Two Times: Recover records modified between to dates / times.

Top Level Candidate Scan

CopyStorm/Restore will apply record selector filters & consider Point-In-Time Configuration to determine which lineage entries are top-level candidates

Reference Candidate Scan

When restoring records, users can control how parent or reference records are evaluated as candidates using the following Reference Candidate Scan options:

Do Not Scan Old Lineage

• Parent Records will not be added as candidates unless they are HEAD or the referenced record has no lineage.

Require Consistent Relationships

• This option ensures that restored reference relationships remain consistent with HEAD lineage entries in Salesforce.
• Parent records are only added as candidates if they belong to a lineage and the HEAD of that lineage exists in Salesforce.
• In these cases, the reference ID in the top-level record will be replaced with the HEAD ID from the lineage.
• If a reference record has no lineage, the original reference ID is left unchanged.

Scan Old Lineage

• Parent records will be added as candidates regardless of whether they are the HEAD of their lineage or whether they establish a consistent relationship.
  All lineage versions are treated as valid candidates.

Related Lists Candidate Scan

When restoring records, users can control how child records (typically related lists) are evaluated as candidates using the following Related Lists Candidate Scan options:

Do Not Scan Old Lineage

• Only HEAD lineage records are considered valid child candidates.
• Child records will not be added as candidates unless they are the HEAD of their lineage.

Require Consistent Relationships

• Ensures that restored child relationships remain consistent with HEAD lineage entries in Salesforce.
  Child records are only added as candidates if they belong to a lineage and the HEAD of that lineage exists in Salesforce.
• In these cases, the relationship will point to the HEAD record.
• If a child record has no lineage, it will be used as-is.

Scan Old Lineage

• Child records will be added as candidates regardless of whether they are the HEAD of their lineage or whether they establish a consistent relationship.
• All lineage versions are treated as valid candidates.

Where is Record Lineage Stored?

Record Lineage data is stored in the CopyStorm Database in a table called CopyForceRecordLineage.