Streaming API (Real-Time Events)
Want your warehouse, middleware or notification system to know the moment an invoice posts? Salesforce's standard eventing — Change Data Capture and platform events — works on REDA Financials objects like on any custom objects. The package publishes no proprietary event bus, which is good news: you configure standard mechanisms you already govern, with no vendor-specific consumer to build.
Change Data Capture on accounting objects
Enable CDC for the objects you care about
Setup → Change Data Capture → select the refin__ objects (Sales Invoice, Purchase Invoice, Cash Receipt, Accounting Transaction…). Each gets a standard change-event channel.
Subscribe from your consumer
CometD/gRPC subscribers, or Flows/Apex triggers on the change events — standard patterns. Events carry the changed fields and the change type.
Filter for the transitions that matter
The accounting-significant moment is usually the status change: refin__Status__c arriving at 'Posted' (document entered the books) or leaving it (unposted/voided). For ledger-level feeds, CDC on refin__Accounting_Transaction__c streams the actual postings.
Proven consumer patterns
- Warehouse sync: CDC on Accounting Transaction → append-only ledger replica, always current.
- Notifications: a record-triggered Flow on Sales Invoice (fires on API and UI changes alike) posting to your chat tool when large invoices post.
- Downstream systems: payment files, property systems — trigger on the posted transition rather than polling.
What ships versus what you enable
| Mechanism | Packaged? | Notes |
|---|---|---|
Platform events (__e) | None ship | The package publishes zero custom events — don't hunt the event picker for REDA channels |
| Change Data Capture | Nothing pre-enabled | You select the refin__ objects in Setup; channels follow the standard naming — refin__Sales_Invoice__ChangeEvent and friends |
| Webhooks / outbound HTTP | None ship | The package's only outbound calls are its own two service integrations (AI, FX rates); event delivery to your systems is yours to configure via standard mechanisms |
| Record-triggered Flows / triggers | Yours to build | Fire on API and UI changes alike — often the simplest "streaming" consumer for a single org-side reaction |
refin__ objects — allocations, event volume from posting bursts, field-level payloads — is a property of your org's configuration and edition. Enable, subscribe, and post a test document end-to-end before designing the production consumer around assumptions.
Choosing your signal
| Need | Best mechanism | Why |
|---|---|---|
| External system mirrors accounting changes continuously | CDC subscription (CometD/gRPC) | Ordered, replayable, delivered outside the transaction — built for external consumers |
| One in-org reaction to a posting | Record-triggered Flow on the status change | No subscriber infrastructure; the fired condition is the filter |
| Nightly warehouse loads, no real-time need | Scheduled REST/Bulk query polling | Simplest to operate; the ledger is queryable truth — streaming is an optimisation, not a requirement |
| Ledger-level replica (every debit and credit) | CDC on refin__Accounting_Transaction__c | Mirrors effects rather than documents; append-mostly by nature |
A worked consumer at Meridian
Meridian Properties Group's finance warehouse subscribes to refin__Accounting_Transaction__ChangeEvent after enabling CDC on the ledger object. The consumer appends creates, marks deletes (an unpost deletes ledger rows — the deletion event is the reversal signal), and keys everything on record Id. The nightly reconciliation job then compares warehouse balances to a Bulk query of the same object — streaming keeps the day current, the batch proves it stayed honest. When the auditors asked how the replica handles a voided invoice, the answer was one sentence: the ledger stream carries the void's accounting rows like any others.
Common mistakes to avoid
| Mistake | Why it hurts | Do this instead |
|---|---|---|
| Treating 'Posted' as a once-only event | Documents unpost and repost — "seen once" consumers double-count or miss reversals | Key on Id + transition; process status changes, not statuses |
| Enabling CDC on every refin object "to be safe" | Allocations burn on channels nobody consumes; the ledger object alone is high-volume | Enable exactly what has a consumer; add channels when consumers exist |
| Building a real-time pipe for a daily report | Streaming infrastructure to answer a question polling answers in one query | Match the mechanism to the freshness requirement — the choosing table above |
| Expecting REDA-specific event payloads | There are none — events are standard change events with changed fields and change type | Design consumers on the standard CDC envelope; it's fully documented platform behavior |
Where to go next
- REST API — the request/response counterpart.
- Salesforce Flows Integration — declarative consumers.
- API Overview — the full landscape.
Frequently asked questions
Standard CDC already delivers reliable, ordered, replayable change events under your org's governance and limits — a proprietary bus would duplicate that with less tooling. Small stable surface, standard everything else.
Yes — standard CDC allocations apply per your Salesforce edition. Enable the objects you'll actually consume; the ledger object is high-volume by nature, so size accordingly.
Same recipe: CDC (or a record-triggered Flow) on refin__Bank_Reconciliation__c watching Status reach 'Completed' or 'Approved'. Any object, any transition — that's the beauty of the standard mechanism.
Yes — CDC captures data changes regardless of who made them, so documents generated by recurring templates or posted by scheduled jobs stream to your consumer like user actions. Expect bursts around the nightly schedule times.
No packaged webhooks exist. The standard architectures are: an external subscriber on the CDC channel (pull-style streaming), or your own Flow/Apex reacting to the change and making the callout under your org's remote-site and credential governance.
Was this article helpful?