Filtering Child Records

When migrating parent-child relationships — such as incidents and their journal entries — the child step should only extract records that belong to parents that were actually migrated. Table correlations enable Precision Bridge to automatically configure the child step's filter, eliminating the need to manually build complex IN-list filters.

The Problem

Consider migrating incidents and their journal entries:

1. Parent step migrates 500 incidents (out of 100,000 in the source)
2. Child step needs to migrate journal entries — but only for those 500 incidents

Without automatic filtering, you would need to manually construct a filter like:

element_id IN (id_1, id_2, id_3, ..., id_500)

This is impractical — the list changes every time the parent step runs, and for large migrations it could contain thousands of IDs.

How Auto-Configuration Works

When these conditions are met, Precision Bridge automatically populates the child step's filter:

1. The parent step has a table correlation enabled — The correlation cache contains the source IDs of all migrated parent records
2. The child step references the parent's correlation — PB detects the relationship and auto-populates the filter

At execution time, PB:

1. Reads the parent's correlation cache to get all source IDs
2. Adds an IN condition to the child step's filter, matching the child's reference field against those source IDs
3. The child extracts only records that reference a migrated parent

This happens dynamically at execution time, so the filter always reflects the current state of the correlation cache.

Prerequisites

Requirement	Details
Parent step must have run	The correlation cache is populated during execution. If the parent hasn't run, the cache is empty and the child filter matches no records.
Table correlation must be enabled	The parent step's Output tab must have the correlation toggle turned on.
Correlation cache must contain data	If the parent ran but migrated zero records (e.g., due to its own filter), the cache is empty.

Combining Auto-Filtering with ID Mappings

A single correlation serves double duty:

1. Filters the child step to extract only relevant records
2. Translates reference fields via ID mappings on the child step

For example, when migrating journal entries after incidents:

• The incidents correlation auto-configures the journal entries filter (only extract entries for migrated incidents)
• An ID mapping on the element_id field uses the same incidents correlation to translate the source incident ID to the target incident ID

This is the most common pattern — set up a correlation once on the parent, and it handles both filtering and ID translation for the child.

Overriding the Auto-Generated Filter

You can modify the auto-configured filter:

• Add conditions — For example, filter journal entries to only include comments (not work notes) by adding a type condition
• Replace entirely — Switch to a native filter or rebuild from scratch
• Disable — Remove the correlation reference to prevent auto-configuration

Note: If you manually edit the child filter and re-run the parent step, PB may update the auto-configured portion with the new parent IDs. Your additional manual conditions are preserved.

Example: Incidents and Journal Entries

Setup:

1. Incidents step (parent)

   • Source table: incident
   • Output tab: Table correlation enabled → incidents correlation
   • Runs first, migrates 500 incidents

2. Journal Entries step (child)

   • Source table: sys_journal_field
   • Reference field: element_id (points to the incident's sys_id)

What happens:

1. The Incidents step runs and populates the correlation cache with 500 source-to-target ID pairs
2. When the Journal Entries step runs, PB auto-configures its filter: element_id IN (incident_source_id_1, incident_source_id_2, ..., incident_source_id_500)
3. The Journal Entries step extracts only entries belonging to the 500 migrated incidents
4. ID mappings on the Journal Entries step use the same incidents correlation to translate element_id to the target incident ID

Troubleshooting

Child step extracts no records

1. Parent step has not run — The correlation cache is empty. Run the parent step first.
2. Parent step migrated zero records — Review the parent's filter; it may be too restrictive.
3. Correlation not enabled — Verify the parent step's Output tab has the toggle on.
4. Reference field mismatch — Verify the child's reference field actually contains the parent's source IDs.

Filter returns wrong records

1. Stale cache — If you re-ran the parent with a different filter, the cache now contains different IDs. Re-run the child step.
2. Multiple parent tables — If the child references records from multiple parent tables (e.g., journal entries for both incidents and problems), the auto-filter only covers one parent.

Related Documentation

• Why Use Table Correlations — Motivation and when to use correlations
• Setting Up Correlations — Enabling correlations on the Output tab
• ID Mappings — Using correlations to translate reference fields
• Chaining Correlations — When parent tables have their own reference fields
• Child Filter Auto-Configuration (Migrate Records) — Detailed reference on auto-configuration mechanics
• Configuring the Filter — Full reference for all filter modes
• correlation_keys() — Formula function for retrieving all correlated source IDs