Child Filter Auto-Configuration

When migrating parent-child relationships — such as incidents and their journal entries, or requests and their request items — the child step needs to extract only the records that belong to parents that were actually migrated. Precision Bridge can automatically configure the child step's filter to achieve this, eliminating the need to manually construct complex IN-list filters.

The Parent-Child Problem

Consider a typical parent-child migration:

1. Parent step — Migrate Records step that extracts and loads incidents
2. Child step — Migrate Records step that extracts and loads journal entries for those incidents

The child step should only extract journal entries that belong to incidents that were successfully migrated by the parent step. Without auto-configuration, you would need to manually build a filter like:

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

This is impractical for large migrations with thousands of parent records, and the list of IDs changes every time the parent step runs.

How Auto-Configuration Works

Precision Bridge solves this problem automatically when the following conditions are met:

1. The parent step has table correlations enabled — On the parent step's Output tab, the table correlation toggle is turned on, which causes PB to write source-to-target ID pairs into the correlation's in-memory cache as the parent step migrates records.
2. The child step references the parent's correlation — When PB detects that a child step is related to a parent step via a table correlation, it can auto-populate the child's filter.

When auto-configuration kicks in, Precision Bridge:

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

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

Prerequisites

For child filter auto-configuration to work:

Requirement	Details
Parent step must have run earlier in the same execution	The correlation cache is in-memory and starts empty at the beginning of every run. It is populated when the parent step migrates records. If the parent has not run in the current execution, the cache holds no source IDs to feed the child filter and the child step will extract no records.
Table correlation must be enabled	The parent step's Output tab must have the table correlation toggle turned on.
Correlation cache must contain data	If the parent step ran but migrated zero records (e.g., due to its own filter), the correlation cache will be empty.

Identifying Auto-Configured Filters

When a child step's filter has been auto-configured, you will see the generated filter conditions on the Filter tab. The auto-generated conditions are typically:

• An IN condition on the child's reference field (e.g., element_id)
• The value list contains the source IDs from the parent's correlation cache

The filter is visually identical to a manually created filter — the only difference is that PB populated it automatically.

Overriding the Auto-Generated Filter

You can modify the auto-configured filter at any time:

• Add additional conditions — For example, filter journal entries to only include comments (not work notes) by adding a type condition alongside the auto-generated parent ID filter.
• Replace the filter entirely — Switch to a native filter or rebuild the standard filter from scratch. The auto-generated conditions are not locked.
• Remove the auto-configuration — If you do not want PB to auto-populate the child filter, you can disable the parent correlation or manually configure the child's filter before execution.

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

Common Pitfalls

Child step extracts no records

If the child step runs but extracts zero records, check these common causes:

1. Parent step has not run yet — The correlation cache is empty. Run the parent step first.
2. Parent step migrated zero records — The parent's filter may be too restrictive, or the source table may be empty. Check the parent step's execution results.
3. Correlation cache is empty — Verify that the parent step's Output tab has the table correlation toggle enabled. If correlations were disabled during the parent run, no IDs were cached.
4. Reference field mismatch — The child filter is matching on the wrong field. Verify that the child's reference field (e.g., element_id) actually contains the parent's source IDs.

Filter looks correct but returns wrong records

1. Parent step ran with a different filter earlier in the same procedure — The correlation cache reflects whatever the parent step migrated during the current run. If the parent step was modified between runs, re-execute the procedure so the child step sees the cache produced by the updated parent 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-configured filter only covers one parent. You may need to run the child step once per parent or configure the filter manually.

Example: Incidents and Journal Entries

Setup:

1. Incidents step (parent)

   • Source table: incident
   • Output tab: Table correlation enabled
   • 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 journal entries belonging to the 500 migrated incidents.
4. ID mappings on the Journal Entries step use the same correlation to translate element_id from source incident IDs to target incident IDs.

This pattern scales to any parent-child relationship and eliminates the need to manually manage ID lists.

Related Documentation

• Why Use Table Correlations — Motivation and when to use correlations
• Setting Up Correlations — Enabling correlations on the parent step's Output tab
• ID Mappings — Using correlations to translate reference fields on child steps
• Chaining Correlations — When parent tables have reference fields to other parents
• Configuring Field Mappings — All mapping types including the ID mapping type
• Configuring the Filter — Full reference for the Filter tab and all filter modes
• Migration Strategy — Planning migration order so parent steps always run before child steps