Quand une organisation veut que Salesforce notifie un système externe en temps réel — ERP, MDM, outil marketing, plateforme logistique — trois patterns natifs s'offrent à elle : Platform Events, Outbound Messages et les Webhooks custom via Apex. Choisir le mauvais pattern génère des architectures fragiles, des pertes de données ou des maintenances coûteuses. Voici comment choisir.
Les 3 patterns en bref
Platform Events
Mécanisme pub/sub natif Salesforce. Un événement est publié dans un bus de messages, les abonnés le consomment de façon asynchrone. Pattern moderne et recommandé.
Outbound Messages
Mécanisme legacy basé sur SOAP. Campaign notifie directement un endpoint externe quand un enregistrement change. Simple mais vieillissant.
Webhooks (Apex Callout)
Appel HTTP custom depuis un trigger ou un Flow via Apex. Le plus flexible mais aussi le plus complexe à maintenir et à sécuriser.
Platform Events — le pattern moderne
Les Platform Events sont le mécanisme d'intégration événementielle natif de Salesforce, introduit dans la Spring '17. Ils s'appuient sur un bus de messages (CometD / Bayeux protocol) qui permet de découpler Salesforce du système consommateur.
Comment ça fonctionne
- On définit un objet Platform Event (comme un objet Salesforce custom, avec des champs)
- Salesforce publie un événement via Apex (
EventBus.publish()) ou via un Flow
- Les abonnés — systèmes externes, autres orgs Salesforce, Apex triggers — consomment les événements en s'abonnant au channel
/event/MonEvenement__e
- Les événements sont conservés 72 heures dans le bus — si le consommateur est temporairement indisponible, il peut reprendre là où il s'était arrêté
Points forts
- Découplage total — Salesforce ne sait pas qui consomme l'événement, ni si quelqu'un le consomme. Pas de dépendance à la disponibilité du système cible.
- Rétention 72h et replay — les consommateurs peuvent rejouer les événements manqués via un ReplayId
- Compatible avec les governor limits — la publication d'un Platform Event ne compte pas comme un DML dans les limits Apex
- Multi-consommateurs — plusieurs systèmes peuvent s'abonner au même événement
Limites
- Le consommateur doit maintenir une connexion CometD active ou être un système compatible (MuleSoft, Heroku, ESB…)
- Pas de garantie d'ordre des événements dans tous les cas
- Allocation d'événements mensuelle selon la licence (250 000 à plusieurs millions selon l'édition)
💡 Cas d'usage idéal : notifier un ESB ou un middleware d'intégration (MuleSoft, Azure Service Bus, Kafka) quand une opportunité est gagnée, qu'un compte est créé ou qu'une commande est validée. Le middleware consomme l'événement et orchestre la suite.
Outbound Messages — le pattern legacy
Les Outbound Messages existent depuis les débuts de Salesforce. Ils sont configurés via les Workflow Rules (désormais dépréciées) ou les Process Builders (également dépréciés) et envoient un message SOAP à un endpoint externe quand un enregistrement répond à des critères.
Comment ça fonctionne
- Configuration déclarative dans les Workflow Rules : "quand l'opportunité passe à Fermée Gagnée, envoyer un Outbound Message"
- Salesforce envoie automatiquement un payload SOAP avec les champs configurés vers l'endpoint
- L'endpoint doit répondre avec un
Ack (accusé de réception) — sinon Salesforce effectue des retry pendant 24h
Points forts
- Zéro code — configuration 100% déclarative
- Retry natif — Salesforce gère les retry automatiquement jusqu'à 24h
- Garantie de livraison — avec l'Ack, on sait que le message a bien été reçu
Limites
- Dépendant des Workflow Rules — ces dernières sont dépréciées par Salesforce. Il est déconseillé de créer de nouveaux Outbound Messages aujourd'hui.
- SOAP uniquement — peu de systèmes modernes exposent des endpoints SOAP natifs
- Payload limité — seuls les champs configurés sont envoyés, pas de logique dynamique
- Un seul endpoint par message — pas de multi-consommateurs natif
⚠️ Outbound Messages en 2026 : si vous avez encore des Outbound Messages en production, ils fonctionnent — mais ne créez pas de nouveaux. Migrez vers Platform Events ou des Apex Callouts selon votre besoin. La dépréciation des Workflow Rules rend ce mécanisme orphelin.
Webhooks via Apex Callout — le pattern custom
Quand ni les Platform Events ni les Outbound Messages ne conviennent, on peut réaliser un appel HTTP direct depuis Apex vers un endpoint externe — c'est ce qu'on appelle communément un "webhook Salesforce", même si Salesforce n'a pas de mécanisme webhook natif au sens strict.
Comment ça fonctionne
- Un trigger Apex, un Flow ou une action invocable appelle une méthode Apex marquée
@future(callout=true) ou implémentant Queueable
- La méthode effectue un appel HTTP REST vers l'endpoint externe avec le payload souhaité
- Le endpoint répond — Salesforce reçoit la réponse mais ne la traite que si le code le prévoit
Points forts
- Flexibilité totale — payload custom, headers personnalisés, authentification OAuth, logique métier dans le payload
- Compatible REST — s'intègre avec n'importe quel endpoint HTTP moderne
- Réponse exploitable — le code peut lire la réponse et agir en conséquence (mettre à jour un champ, loguer une erreur…)
Limites
- Aucune garantie de livraison native — si l'endpoint est indisponible, le message est perdu sauf si on implémente sa propre gestion de retry
- Callout impossible dans un trigger synchrone — il faut passer par
@future ou Queueable, ce qui introduit de l'asynchronisme
- Governor limits callouts — 100 callouts maximum par transaction
- Complexité de maintenance — authentification, gestion d'erreurs, retry, logs — tout est à coder
Comparatif synthétique
| Critère | Platform Events | Outbound Messages | Apex Callout |
|---|
| Protocole | CometD / pub-sub | SOAP | HTTP REST |
| Configuration | Déclaratif + Apex | Déclaratif | Code Apex |
| Garantie de livraison | 72h rétention | Retry 24h + Ack | Aucune native |
| Multi-consommateurs | Natif | Non | Custom |
| Flexibilité payload | Champs définis | Champs configurés | Totale |
| Complexité setup | Moyenne | Faible | Élevée |
| Recommandé en 2026 | ✓ Oui | Legacy | Cas spécifiques |
Comment choisir
Choisir Platform Events si…
- Vous avez un ESB, un middleware (MuleSoft, Azure Service Bus, Kafka) ou une plateforme capable de s'abonner à un channel CometD
- Plusieurs systèmes doivent consommer le même événement
- La rétention des événements et le replay sont importants pour votre cas d'usage
- Vous voulez un découplage propre entre Salesforce et les systèmes cibles
Choisir Apex Callout si…
- Le système cible expose un endpoint REST et ne peut pas s'abonner à un bus de messages
- Vous avez besoin d'une réponse synchrone exploitable (récupérer un ID externe, vérifier une disponibilité…)
- Le payload doit être construit dynamiquement avec une logique métier complexe
Ne pas choisir Outbound Messages pour du nouveau développement
Simple. Les Workflow Rules sont dépréciées, SOAP est vieillissant, et les Platform Events couvrent tous les cas d'usage des Outbound Messages avec plus de flexibilité.
💡 Pattern hybride recommandé : publier un Platform Event depuis Apex ou un Flow, et laisser un middleware s'abonner et effectuer le callout REST vers le système cible. Vous combinez le découplage des Platform Events avec la flexibilité des appels HTTP — sans les contraintes des governor limits callout dans Salesforce.
Conclusion
En 2026, Platform Events est le pattern à privilégier pour les nouvelles intégrations événementielles Salesforce. Il offre découplage, rétention et multi-consommateurs — sans les compromis des Outbound Messages ou la complexité des Apex Callouts. Réservez les callouts Apex aux cas où vous avez besoin d'une réponse synchrone exploitable ou d'un payload très custom que les Platform Events ne permettent pas d'exprimer simplement.
When an organisation wants Salesforce to notify an external system in real time — ERP, MDM, marketing tool, logistics platform — three native patterns are available: Platform Events, Outbound Messages and custom Webhooks via Apex. Choosing the wrong pattern generates fragile architectures, data loss or costly maintenance. Here's how to choose.
The 3 patterns in brief
Platform Events
Native Salesforce pub/sub mechanism. An event is published to a message bus; subscribers consume it asynchronously. Modern and recommended pattern.
Outbound Messages
Legacy SOAP-based mechanism. Salesforce notifies an external endpoint directly when a record changes. Simple but ageing.
Webhooks (Apex Callout)
Custom HTTP call from a trigger or Flow via Apex. The most flexible but also the most complex to maintain and secure.
Platform Events — the modern pattern
Platform Events are Salesforce's native event-driven integration mechanism, introduced in Spring '17. They rely on a message bus (CometD / Bayeux protocol) that decouples Salesforce from the consuming system.
How it works
- Define a Platform Event object (like a custom Salesforce object, with fields)
- Salesforce publishes an event via Apex (
EventBus.publish()) or a Flow
- Subscribers — external systems, other Salesforce orgs, Apex triggers — consume events by subscribing to the
/event/MyEvent__e channel
- Events are retained for 72 hours — if a consumer is temporarily unavailable, it can resume from where it left off
Strengths
- Full decoupling — Salesforce doesn't know who consumes the event, or if anyone does. No dependency on the target system's availability.
- 72h retention and replay — consumers can replay missed events via a ReplayId
- Governor limit friendly — publishing a Platform Event doesn't count as a DML in Apex limits
- Multi-consumer — multiple systems can subscribe to the same event
Limitations
- The consumer must maintain an active CometD connection or be a compatible system (MuleSoft, Heroku, ESB…)
- No guarantee of event ordering in all cases
- Monthly event allocation varies by licence (250,000 to several million depending on edition)
💡 Ideal use case: notify an ESB or integration middleware (MuleSoft, Azure Service Bus, Kafka) when an opportunity is won, an account is created or an order is validated. The middleware consumes the event and orchestrates the rest.
Outbound Messages — the legacy pattern
Outbound Messages have existed since Salesforce's early days. Configured via Workflow Rules (now deprecated) or Process Builders (also deprecated), they send a SOAP message to an external endpoint when a record meets certain criteria.
How it works
- Declarative configuration in Workflow Rules: "when opportunity moves to Closed Won, send an Outbound Message"
- Salesforce automatically sends a SOAP payload with configured fields to the endpoint
- The endpoint must respond with an
Ack (acknowledgement) — otherwise Salesforce retries for 24 hours
Strengths
- Zero code — 100% declarative configuration
- Native retry — Salesforce handles retries automatically for up to 24 hours
- Delivery guarantee — with Ack, you know the message was received
Limitations
- Dependent on Workflow Rules — which are deprecated by Salesforce. Creating new Outbound Messages is not recommended today.
- SOAP only — few modern systems expose native SOAP endpoints
- Limited payload — only configured fields are sent, no dynamic logic
- Single endpoint per message — no native multi-consumer
⚠️ Outbound Messages in 2026: if you still have Outbound Messages in production, they work — but don't create new ones. Migrate to Platform Events or Apex Callouts depending on your needs. The Workflow Rules deprecation makes this mechanism an orphan.
Webhooks via Apex Callout — the custom pattern
When neither Platform Events nor Outbound Messages fit, you can make a direct HTTP call from Apex to an external endpoint — commonly called a "Salesforce webhook", even though Salesforce has no native webhook mechanism in the strict sense.
How it works
- An Apex trigger, Flow or invocable action calls an Apex method marked
@future(callout=true) or implementing Queueable
- The method makes an HTTP REST call to the external endpoint with the desired payload
- The endpoint responds — Salesforce receives the response but only processes it if the code handles it
Strengths
- Total flexibility — custom payload, personalised headers, OAuth authentication, business logic in the payload
- REST compatible — integrates with any modern HTTP endpoint
- Usable response — code can read the response and act accordingly (update a field, log an error…)
Limitations
- No native delivery guarantee — if the endpoint is unavailable, the message is lost unless retry logic is implemented
- Callout impossible in a synchronous trigger — must use
@future or Queueable, introducing asynchronism
- Callout governor limits — 100 callouts maximum per transaction
- Maintenance complexity — authentication, error handling, retry, logging — all must be coded
Summary comparison
| Criterion | Platform Events | Outbound Messages | Apex Callout |
|---|
| Protocol | CometD / pub-sub | SOAP | HTTP REST |
| Configuration | Declarative + Apex | Declarative | Apex code |
| Delivery guarantee | 72h retention | 24h retry + Ack | None native |
| Multi-consumer | Native | No | Custom |
| Payload flexibility | Defined fields | Configured fields | Total |
| Setup complexity | Medium | Low | High |
| Recommended in 2026 | ✓ Yes | Legacy | Specific cases |
How to choose
Choose Platform Events if…
- You have an ESB, middleware (MuleSoft, Azure Service Bus, Kafka) or platform capable of subscribing to a CometD channel
- Multiple systems need to consume the same event
- Event retention and replay matter for your use case
- You want clean decoupling between Salesforce and target systems
Choose Apex Callout if…
- The target system exposes a REST endpoint and cannot subscribe to a message bus
- You need a usable synchronous response (retrieve an external ID, check availability…)
- The payload must be dynamically built with complex business logic
Don't choose Outbound Messages for new development
Simple. Workflow Rules are deprecated, SOAP is ageing, and Platform Events cover all Outbound Message use cases with more flexibility.
💡 Recommended hybrid pattern: publish a Platform Event from Apex or a Flow, and let middleware subscribe and perform the REST callout to the target system. You combine Platform Events' decoupling with HTTP call flexibility — without Salesforce's callout governor limit constraints.
Conclusion
In 2026, Platform Events is the pattern to prioritise for new Salesforce event-driven integrations. It offers decoupling, retention and multi-consumer support — without the compromises of Outbound Messages or the complexity of Apex Callouts. Reserve Apex Callouts for cases where you need a usable synchronous response or a very custom payload that Platform Events cannot express simply.
Un projet d'intégration Salesforce à concevoir ?A Salesforce integration project to design?
Architecture, choix du pattern, implémentation — je peux vous accompagner. Réponse sous 24h.Architecture, pattern selection, implementation — I can support you. Reply within 24 hours.
Parlons de votre projet →Let's talk →