Salesforce Filtered Channels: A Practical Guide

Salesforce event-driven integrations often begin with a simple subscription: consume an event stream and decide in the client which messages matter. That works, but it can become wasteful as event volume grows.

Filtered custom channels move part of that decision to Salesforce.

What Is a Custom Channel?

A custom channel groups one or more event entities behind a channel that a subscriber can consume. Salesforce models the configuration with two metadata types:

PlatformEventChannel defines the channel.
PlatformEventChannelMember adds an event or change-event entity to that channel.

A channel uses ChannelType = event for platform events or ChannelType = data for Change Data Capture (CDC). A single channel does not mix those two event types.

For CDC, a custom channel might combine AccountChangeEvent and ContactChangeEvent into a customer-oriented stream.

Where Filtering Fits

Each channel member can have a filterExpression. Salesforce evaluates that expression before delivering events on the custom channel.

Conceptually:

Salesforce record changes
        |
        v
Change Data Capture
        |
        v
Custom channel filter
     /       \
 relevant   ignored for this channel
    |
    v
Subscriber

Instead of delivering every Account change and writing client code to discard most of them, the subscriber receives the subset selected by the channel member.

Example Scenario

Suppose an integration only cares about Account updates for Banking and Agriculture customers. A channel member can express that rule using filterExpression rather than requiring every subscriber to implement the same filtering logic.

Salesforce's examples show that filters can combine event operation types and field values. Filter expressions use SOQL-like syntax, but support a subset of SOQL operators and field types, so they should not be treated as arbitrary SOQL WHERE clauses.

Why Use Server-Side Filtering?

Filtered channels can:

reduce irrelevant event delivery to a subscriber;
reduce client-side filtering code;
reduce network and deserialization work;
help an integration stay focused on a business-specific event stream;
reduce delivered-event consumption compared with subscribing to a broad unfiltered stream.

The last point needs careful wording: filtering changes what is delivered through the filtered channel. It does not mean the underlying business change never generated a CDC event on Salesforce's event infrastructure.

Filtered Channels Are a Contract

Treat the filter as part of the integration contract, not as a hidden optimization.

If a consumer expects only a certain region, operation, or business state, document that rule with the channel. A future change to the filter can change the subscriber's observable behavior just as surely as changing an API response can.

Filter Fields and CDC Payloads

Salesforce documents a useful CDC behavior: fields referenced by a filter expression are automatically included in delivered change events. You don't need to duplicate those same fields in enrichedFields just to make them available to the subscriber.

That becomes important when designing a channel that uses both filtering and enrichment.

What Filtering Does Not Solve

A filtered channel does not remove the need for:

idempotent event processing;
replay/checkpoint handling;
downstream backpressure;
schema-evolution planning;
error handling and dead-letter/recovery strategies;
observability around lag and failures.

It makes the event stream more relevant. It does not make distributed systems failure modes disappear.

When I Would Use It

Filtered channels are especially attractive when a high-volume source produces many changes but an integration needs a stable, well-defined subset. They are less compelling when nearly every event is relevant or when the filter rule changes so frequently that maintaining it as Salesforce metadata becomes operationally awkward.