Salesforce Filtered Channels: Pros, Cons, Limits, and Gotchas
Filtered channels are powerful precisely because they change the boundary of an event integration. That deserves a tradeoff analysis, not just a setup tutorial.
Pros
Less noise at the subscriber
Salesforce evaluates the channel-member filter and delivers the matching subset rather than forcing the client to discard every irrelevant event.
Simpler consumers
A consumer can subscribe to a business-oriented stream instead of embedding the same coarse filter logic in every client.
Lower unnecessary delivery work
Fewer irrelevant deliveries mean less network, deserialization, and client processing work. Salesforce also positions filtering as a way to reduce event delivery consumption compared with broad subscriptions.
Better stream semantics
A well-named channel plus a documented filter can express a useful integration contract such as "customer updates relevant to region X."
Cons
Configuration coupling
The consumer's observable stream now depends on Salesforce metadata. Changing a filter can be a behavioral breaking change even if the event schema did not change.
Limited expression model
Salesforce documents filter expressions as SOQL-based with a subset of operators and supported field types. Application code remains more expressive.
Harder ownership questions
Who owns the rule: Salesforce platform team, integration team, or consuming application? Decide before production.
Gotchas
Filter fields are automatically included
For CDC, fields referenced in a filter expression are included in delivered events. Don't duplicate them unnecessarily in enrichedFields.
Filtering does not mean the source change never became an event
Think of filtering primarily as delivery selection for the custom channel, not as preventing Salesforce from recognizing the underlying CDC change.
A too-narrow filter can silently become data loss from the consumer's perspective
Test transitions into and out of the matching state, nulls, operation types, and representative updates.
Reliability still belongs to the subscriber
Replay IDs, idempotency, duplicate handling, backpressure, error recovery, and monitoring remain necessary.
Salesforce's event bus stores platform and CDC events for 72 hours, and Pub/Sub API can replay retained events using replay IDs. That recovery window is valuable, but it is not a substitute for a recovery design.