← All articles
Salesforce · Event-Driven Architecture · Architecture · Quick Reads

Salesforce Filtered Channels vs Client-Side Event Filtering

Where should an event-routing rule live: in Salesforce or in the subscriber?

Both approaches are valid. The right choice depends on whether the rule defines the stream contract or is merely local consumer behavior.

Client-Side Filtering

The subscriber receives a broad stream and evaluates each event itself.

Salesforce -> all subscribed events -> consumer -> filter -> processing

Advantages

  • filtering logic can change with the application deployment;
  • different consumers can make independent decisions;
  • the client has full programming-language expressiveness;
  • useful when almost every event is already relevant.

Costs

  • irrelevant events still cross the subscription boundary;
  • every consumer may duplicate filtering logic;
  • more messages must be received/deserialized;
  • broad delivery can consume more event-delivery capacity.

Salesforce Filtered Channel

Salesforce evaluates the channel member's filterExpression and delivers the matching subset on that custom channel.

Salesforce -> channel filter -> relevant events -> consumer

Advantages

  • fewer irrelevant deliveries;
  • simpler consumer code;
  • a reusable server-side definition of the stream;
  • useful when the business subset is stable and selective.

Costs

  • filter syntax is intentionally more limited than application code;
  • changing the rule is a metadata/configuration change;
  • a bad filter can cause consumers to miss events they expected;
  • teams must govern the channel as an integration contract.

The Architectural Question

If the rule says "this is what the stream means", a filtered channel is often a good home.

If the rule says "this particular application currently doesn't care about this event", client-side filtering may be more appropriate.

Hybrid Is Often Best

Server-side filtering and client-side validation are not mutually exclusive.

Use Salesforce to remove obvious noise and define the coarse stream contract. Then let the consumer apply local validation, authorization context, deduplication, and downstream routing.

Don't Confuse Filtering with Reliability

Neither approach solves replay, duplicate handling, idempotency, poison events, or backpressure. Those remain subscriber architecture responsibilities.

References

CONTINUE READING

Explore closely related architecture, integration and implementation topics.