Set up Salesforce platform events

Platform events are a native Salesforce feature that lets your org emit a real-time event whenever a case is created or updated. Tekst subscribes to these events so it can start processing a case the moment it changes, without polling.

Platform events work similarly to Change Data Capture (CDC), but they are far more configurable and customizable, giving you full control over which changes are broadcast and what each event carries. The trade-off is that, unlike CDC, they are not available out of the box: your Salesforce administrator defines the event, chooses which fields it carries, and decides when it is published. This article walks through that setup and gives our recommendations on which triggers to use and which fields to include.

For a comparison of platform events with the other real-time methods, see the "Real-time access" article (https://support.tekst.com/hc/en-us/articles/19387637761298).

Step 1: Define the platform event

1. Log in as a Salesforce administrator.
2. From "Setup", enter "Platform Events" in the Quick Find box, then select "Platform Events".
3. Click "New Platform Event".
4. For Label, enter a name such as "Tekst Case Event". For Plural Label, enter the plural form, e.g. "Tekst Case Events".
5. Add a Description, for example "Real-time events for case changes sent to Tekst".
6. Keep the Publish Behavior on the default, "Publish After Commit".
7. Click "Save".

Note: Platform event API names always end with the suffix __e. Include this suffix whenever you reference or configure the event.

Salesforce documents this in the Platform Events Basics module on Trailhead.

Step 2: Add the fields

In the "Custom Fields & Relationships" related list of your new event, click "New" to add each field. Platform events support the following field types:

• Checkbox
• Date
• Date/Time
• Number
• Text
• Text Area (Long)

Which fields to include

Keep the event lean. Only two pieces of information are actually required:

• Case identifier - the Case Id (or case number) of the record that changed. A Text field, e.g. Case_Id__c.
• Event type - whether this is a new case or an update, with the value new or update. A Text field, e.g. Event_Type__c.

With just those two fields Tekst can look up the case and fetch everything else it needs through the Salesforce API.

Child-inbox split field (recommended if you use child inboxes). If your Salesforce instance is split into multiple Tekst inboxes (child inboxes), it is worth adding the field that Tekst splits on to the event as well. Sending the split value inside the event lets Tekst route the case to the correct child inbox immediately, rather than after fetching the record. This divides the work across your inboxes earlier and raises the maximum throughput of your org, because the child inboxes have fewer side effects on one another.

Other fields are not used. Any additional fields you add to the event payload are not taken into account by Tekst - it always fetches the full, up-to-date case from Salesforce. There is no benefit to putting case content (subject, description, status, and so on) in the event, so leave those out to keep the payload small.

The exact field names can vary. Map them to Tekst on your dashboard under "Inboxes" > "Config".

Step 3: Publish the event on the right triggers

Defining the event does not fire it - you decide when it is published. The most common way is a record-triggered Flow on the Case object with a "Create Records" element that creates a platform event record. You can also publish from an Apex trigger or from Process Builder. The Platform Events Basics module covers each method.

Which triggers we recommend

Our recommendation is to publish an event on the opening (creation) and the closing of a case:

• On case creation, publish an event with event type new.
• On case close, publish an event with event type update.

This covers the two moments most workflows care about. You can adjust it to your own process (for example, firing on a specific status change or on a particular case type) - platform events are fully configurable, so publish only on the changes that are genuinely relevant.

Watch your event consumption

Be deliberate about how often you fire events. Salesforce meters platform events against your org's allocations: an hourly publishing limit and a 24-hour delivery limit (for example, 25,000 deliveries per day on Enterprise Edition under the standard allocation). Because Tekst is a subscriber, every event you publish counts against that daily delivery allocation.

Firing on every single case update can burn through this allocation quickly and is rarely necessary, since Tekst re-fetches the case anyway. Limiting triggers to open and close keeps consumption predictable. Review your edition's numbers in the Salesforce platform event allocations documentation, and see our "API usage and performance impact" article (https://support.tekst.com/hc/en-us/articles/25926695617810) for how Tekst uses the Salesforce APIs.

Summary

• Define a platform event (remember the __e suffix) and keep the Publish Behavior on "Publish After Commit".
• Include only a case identifier and an event type (new / update); add the child-inbox split field if you use child inboxes; leave all other fields out.
• Publish on case open and close by default, and keep an eye on your Salesforce event allocations before adding more triggers.