Salesforce CDC Enriched Fields: Pros, Cons, Limits, and Gotchas
CDC enriched fields can make a change event far more useful, but they should be designed as an event contract rather than used as a shortcut to copy the whole record.
Pros
Stable correlation data travels with the event
External IDs and routing keys remain available even when they were not changed by the transaction.
Fewer follow-up API calls
If enrichment makes the event independently processable, the subscriber may avoid querying Salesforce for every change.
Lower latency and fewer failure points
Removing a synchronous lookup can simplify the path from event receipt to downstream processing.
Better event-time context
The subscriber can reason from data carried with the event rather than always fetching later record state.
Limits
Salesforce documents support for up to 10 enriched fields on a CDC custom-channel member.
Fields referenced by the member's filter expression are automatically included, so don't waste enrichment slots duplicating them.
Enrichment applies to Change Data Capture custom channels; Salesforce's event-platform guidance distinguishes this from platform-event custom channels.
Gotcha: Available Does Not Mean Changed
This is especially important with Pub/Sub API.
Salesforce documents that Pub/Sub CDC events use Avro and can deserialize with all record fields represented, while unchanged fields have empty values. changedFields tells you which fields actually changed, and nulledFields identifies fields explicitly set to null.
Do not write logic that assumes every visible/non-empty enriched field was modified by the transaction.
Gotcha: Ten Fields Can Become Ten Random Fields
Without design discipline, teams may add whatever the latest consumer requests until the limit is exhausted.
Prefer fields that establish identity, routing, partitioning, or processing context. If a consumer needs a large snapshot, reconsider the integration pattern.
When Enrichment Is the Wrong Tool
Use a query or another data-access pattern when processing requires:
- many fields;
- related-object state;
- a deliberately current snapshot rather than event-time context;
- complex calculations better owned by another service/API.