Home / integration / event-relay-configuration
event-relay-configuration
Use when forwarding Salesforce Platform Events or Change Data Capture to AWS EventBridge via Event Relay. Covers Named Credential + Connection setup, channel selection, event filter design, replay handling. NOT for consuming external events in Salesforce (see pub-sub-api or salesforce-connect) — use integration/aws-salesforce-patterns.
Open the skill folder on GitHub
Event Relay Configuration (Salesforce → AWS EventBridge)
Event Relay is a Salesforce-managed subscriber that forwards platform events and change data capture events to Amazon EventBridge with no code and no middleware. It replaces the DIY pattern of an Apex callout from a platform event trigger, and it replaces a self-hosted Pub/Sub API consumer, by moving the subscription, the replay position, and the retry behaviour into the platform.
What it removes is operational: a process to host, a checkpoint to persist, a consumer to page someone about. What it does not remove is at-least-once delivery, unordered events, and a recovery fallback that can replay up to three days of the event bus. That work moves to the AWS side, where it belongs.
Before Starting
- Confirm the destination is Amazon EventBridge. Event Relay relays "platform
events and change data capture events from Salesforce to Amazon EventBridge." For any other target, this is the wrong tool — use Pub/Sub API with your own consumer, or a Named Credential callout from Apex.
- Establish who owns the AWS account. Creating a relay registers a pending
partner event source in AWS. Until an AWS administrator associates an event bus with it, nothing is delivered and Salesforce reports no error. If you cannot name that person, the integration cannot be completed.
- Determine whether the downstream target is idempotent. This single fact
decides the
relayOptionvalue, and it is far cheaper to establish now than at 06:00 during a recovery. - Baseline the event delivery allocation. A relay is a subscribed client and
consumes the org's daily delivery allocation per client. Query
PlatformEventUsageMetricbefore switching it on.
Core Concepts
Five components, in dependency order
1. The event MyEvent__e / MyObject__ChangeEvent
2. Channel MyChannel__chn PlatformEventChannel
3. Channel member(s) one per event, optional filter PlatformEventChannelMember
4. Credentials ExternalCredential (AwsSv4) + NamedCredential
5. Relay EventRelayConfig -> references (2) and (4)
A channel is a typed stream
"A channel can hold only one type of events." The valid pairs:
channelType | eventType | Carries |
|---|---|---|
event | custom | Custom platform events (__e) |
data | data | Change data capture events |
event | monitoring | Real-Time Event Monitoring events |
Consequence: one relay per event type. An integration spanning custom events and CDC is two channels, two relays, and two partner event sources.
Filter at the channel member, not downstream
PlatformEventChannelMember.filterExpression (API 56.0 and later) is "based on SOQL and supports a subset of SOQL operators and field types" — for example City__c = 'San Francisco'. A filtered event is never delivered, so it never consumes delivery allocation. Filtering in an EventBridge rule costs you the delivery first.
The relay config is mostly immutable
<EventRelayConfig xmlns="http://soap.sforce.com/2006/04/metadata">
<destinationResourceName>callout:AWS_Account</destinationResourceName>
<eventChannel>Order_Events__chn</eventChannel>
<label>Order Events Relay</label>
<relayOption>{"ReplayRecovery":"LATEST"}</relayOption>
<state>STOP</state>
</EventRelayConfig>
destinationResourceNamerequires thecallout:prefix.- On create,
statemay only beSTOP. - "You can update only the
stateandrelayOptionfields and noteventChannelor
destinationResourceName." Repointing the relay means delete and recreate — and a new partner event source the AWS side must associate again.
Replay recovery is a fallback, not the normal path
relayOption accepts exactly two values, {"ReplayRecovery":"LATEST"} (default) and {"ReplayRecovery":"EARLIEST"}. There is no specific-replay-id option — that is a Pub/Sub API capability, not an Event Relay one.
And it usually does not apply. On recovery the relay "attempts to resume sending events from the event bus from where it left off. In rare occasions, if it can't resume after the last relayed event, it uses the error recovery option." When it does apply, EARLIEST means everything still in the bus, up to the three-day retention — not "what you missed."
Retention
High-volume platform event messages are stored for 72 hours (3 days); legacy standard-volume messages for 24 hours. A relay paused longer than the retention window loses whatever aged out, regardless of relayOption.
State semantics
| State | Delivery | Position | Diagnostics |
|---|---|---|---|
RUNNING | Yes | — | — |
PAUSED | No | Preserved (within retention) | Preserved |
STOPPED | No | Discarded — only new events on resume | LastRelayedEventTime and error fields deleted |
ERROR | No | Retried; self-clears to RUNNING on success | Populated |
During an incident, pause — never stop.
Common Patterns
Pattern A — custom platform event to EventBridge
Channel (event/custom) → member per event → AwsSv4 credential pair → relay. Full metadata in