What I ran into
I ran into a case where gate conditions were not behaving as expected. A row should have been skipped based on the condition, but it still got inserted into the target.
At first it looked like a logic issue in the mapping. It turned out to be something deeper in how CDC evaluates updates.
What was happening
The gate condition was checking a column like:
INCFLP = 'C'
But the actual update coming in had:
INCFLP = 'I'
Logically, that should fail the condition and skip the row.
Instead, CDC allowed the row through.

The key detail
The condition was being evaluated using the BEFORE value, not the AFTER value, during update operations.
So CDC saw the old value of the column and decided:
- condition is true
- row is in scope
Even though the new value should have excluded it.
Why this matters
This creates a subtle problem:
- Rows can appear in the wrong target
- Scope decisions are based on outdated values
- You can end up with unexpected inserts or duplicates
From the outside, it looks like CDC is ignoring the condition. In reality, it is evaluating it earlier than expected in the change lifecycle.
What fixed it
The behavior changed after enabling this option in the mapping:
- "Keep the target row if UPDATE causes a change in scope"
With this enabled, CDC handles the scope transition correctly and avoids inserting rows based on stale values.
What changed for me
I used to think gate conditions always look at the final row state.
This made it clear that for updates, timing matters:
- BEFORE values can influence routing decisions
- AFTER values are not always what drive the initial decision
That difference explains a lot of “unexpected” behavior.
Takeaway
If gate conditions look wrong, it is not always a configuration issue.
It can be about which version of the data CDC is using during evaluation.
Understanding that helped me debug cases where rows were landing in targets they should never have reached.
References
- Connect CDC knowledge base - gate condition behavior on updates
- Mapping configuration guide - scope changes and update handling
Have you seen rows passing a gate condition when the current value clearly should not match?
*Precisely Software Inc.