Real Messaging Engine

Architecture

Real Messaging Engine is a layered, event-driven system. Requests flow down; delivery events flow back up into Salesforce.

Layer model

┌─────────────────────────────────────────────┐
│ Salesforce                                  │
│ System of record · Objects · Flow · Apex    │
└───────────────────┬─────────────────────────┘
                    ↓
┌─────────────────────────────────────────────┐
│ Enterprise Intelligence Engine (EIE)        │
│ Schema · Context · AI services · Policy     │
└───────────────────┬─────────────────────────┘
                    ↓
┌─────────────────────────────────────────────┐
│ Real Messaging Engine (RME)                 │
│ Orchestration · Templates · Routing ·       │
│ Consent · Suppression · Retry · Audit       │
└───────────────────┬─────────────────────────┘
                    ↓
┌─────────────────────────────────────────────┐
│ Provider Layer                              │
│ SendGrid · Amazon SES · Azure ACS ·         │
│ Mailgun · Postmark · SparkPost · Future     │
└───────────────────┬─────────────────────────┘
                    ↓
┌─────────────────────────────────────────────┐
│ Customer                                    │
│ Email · Phone · Enterprise inbox            │
└─────────────────────────────────────────────┘

Events return along the reverse path:

Customer → Provider webhook → RME Webhook Service →
Platform Event → Salesforce records → EIE → AI / Analytics

Send sequence

Flow / Apex / REST
      │  publish Message__c (Queued)
      ▼
Routing Service ──► select channel + provider
      │                (policy, consent, cost, failover)
      ▼
Template Service ──► merge + personalization
      │
      ▼
Named Credential ──► provider REST API
      │
      ▼
Provider Message ID ──► Delivery_Status__c (Sent)
      │
      ▼
Webhook (delivered / open / click / bounce / complaint)
      │
      ▼
Platform Event: RME_Delivery_Event__e ──► subscribers

Provider layer

ProviderChannelsNotes
SendGridEmailDedicated IPs, subusers, event webhook
Amazon SESEmailConfiguration sets, SNS event destinations
Azure Communication ServicesEmail, SMSEntra ID auth, EU/US data residency
MailgunEmailRegional endpoints (US/EU)
PostmarkEmailTransactional message streams
SparkPostEmailSubaccounts, high-volume relay
Twilio / VonageSMS, RCS, WhatsApp, VoiceChannel providers
Future providersAnyPluggable provider adapter interface

Providers are configured, not coded. Each provider is a Provider_Config__c record bound to a Named Credential; adding one never requires a code change to your messaging logic.

Bidirectional event flow

Every provider webhook is normalized to one internal event shape before it reaches Salesforce:

{
  "messageId": "a0X5f000001AbCdEAK",
  "providerMessageId": "14c5d75ce93.dfd.64b469",
  "channel": "EMAIL",
  "event": "delivered",
  "timestamp": "2026-08-03T18:22:11Z",
  "recipient": "customer@example.com",
  "provider": "SENDGRID",
  "metadata": { "ip": "168.245.1.1", "tls": true }
}

This normalization is what makes analytics, AI, and reporting provider-agnostic.

Design principles

  1. Salesforce is the system of record. RME never becomes a second database of customers.
  2. No synchronization. Data does not leave and return; it never leaves.
  3. Provider independence. Routing and failover are configuration.
  4. Event-driven. Platform Events decouple delivery from business logic.
  5. Governed. Sharing rules, permission sets, field-level security, and audit logs apply.
  6. Extensible. New channels and providers plug into the same interfaces.

Continue to Communication Providers.

Was this helpful?

Last updated 1 month ago