An Azure real-time data ingestion service.
What you’re seeing is actually expected behavior when using Azure Event Hubs, and it’s not an issue with the platform itself.
Azure Event Hubs is designed as an append-only event streaming service and it guarantees at-least-once delivery, not exactly-once delivery. In simple terms, this means that the same logical action (for example, creating or updating one Outlook calendar item) can result in multiple event messages being delivered to MuleSoft.
On top of that, Microsoft Graph calendar notifications often generate multiple low-level change events for a single update. A calendar edit might trigger separate notifications for metadata changes, body updates, reminder updates, or attendee changes. Event Hubs faithfully captures and forwards all of those notifications. If there are retries, batching, or checkpoint delays, the same event may also be delivered again. This is all normal behavior in event streaming systems.
Because Event Hubs does not perform deduplication, the responsibility for filtering duplicates sits with the consumer in your case, MuleSoft.
The recommended approach is to implement idempotent processing in MuleSoft. Instead of assuming each message is unique, your flow should check whether a given version of an Outlook event has already been processed. You can use metadata such as the Outlook event ID, the changeKey, and the lastModifiedDateTime to determine whether the event is new or a duplicate. If it has already been handled, simply skip it.
It’s also good practice to maintain a small deduplication store. For example, you could store a short-lived key made up of the Outlook Event ID and changeKey in MuleSoft Object Store, Redis, or Cosmos DB with a time-to-live. If the same key appears again, it can safely be ignored.
For batch processing scenarios, another clean approach is to group events by calendar item ID and only process the most recent version based on lastModifiedDateTime. This helps ensure you only apply the final state of the item.
Checkpointing is also important. Make sure your Event Hub listener is configured properly and commits offsets consistently. If checkpointing is delayed or misconfigured, Event Hubs may replay events that were already processed.
Finally, since this is a bidirectional sync between Outlook and Salesforce, make sure you maintain a correlation or mapping table between the two systems. This prevents infinite loops where an update in Outlook triggers Salesforce, which then triggers Outlook again.
Multiple events per logical change are expected with Event Hubs due to its at-least-once delivery model and how Microsoft Graph emits notifications. The correct and supported approach is to handle deduplication and idempotency within MuleSoft.
Helpful References:
https://dori-uw-1.kuma-moon.com/azure/event-hubs/event-hubs-features#delivery-guarantees
https://dori-uw-1.kuma-moon.com/azure/event-hubs/event-hubs-features#event-processing
Hope this helps, Please let us know if you have any questions and concerns.