Event-driven integration lets a source application report what happened while Elaine decides how that event should influence customer engagement. The source remains decoupled from the campaign logic, channels, and downstream actions configured in Elaine.
Typical business events
- A customer registers, completes a purchase, abandons a process, or changes an account.
- A product, booking, contract, service, or fulfillment state changes.
- A web or app interaction is collected through Entirely Intent Signals.
- A connected application needs to trigger a service message or lifecycle automation.
Solution pattern
- The source application assigns a stable event name and correlation identifier.
- It submits the event with the data required to identify the contact and process the occurrence.
- Elaine accepts the event asynchronously and routes it to subscribed automations.
- The automation can update data, evaluate conditions, select content, send messages, wait for later signals, or call an external endpoint.
- Operational monitoring correlates accepted events with subsequent automation and delivery outcomes.
Why use an event instead of a sequence of API calls?
A source application can often submit one meaningful business event instead of implementing a tightly coupled sequence of contact lookup, data update, audience selection, and message calls. Marketing and solution teams can evolve the downstream automation without requiring every change to be released in the source application.
The source does not need to know whether one, several, or no automations currently subscribe to the event. This makes it possible to introduce new reactions later while preserving the original event contract.
Outbound actions and webhooks
An Elaine automation can use supported HTTP actions or business rules to notify another application. Model success, authorization failures, transient failures, and retries as explicit branches. Avoid placing secrets in URLs or content, and keep latency-sensitive automations independent from long-running external calls.
Design considerations
- Define the event as a business fact, not as the name of one current campaign.
- Version incompatible payload changes and validate required fields.
- Use idempotency and correlation identifiers to control duplicates and tracing.
- Do not treat technical acceptance as proof that every downstream action succeeded.
- Separate long waits or parallel lifecycle processes into suitable automations.
- Apply consent, PAC, suppression, and channel eligibility before personal activation.