Fixing mailbox integration errors in Dynamics 365 for Sales

The Problem – Mailbox Integration Errors 

A customer of ours recently encountered an issue with email integration in Dynamics 365, where emails coming into a shared email mailbox were occasionally taking months to make it into the system.  This was causing problems with case management, as this customer uses emails as their primary tool for handling case status and communication.  When we checked the email mailbox alerts, we found errors similar to the following: 

Understanding the Scenario 

One of Dynamics 365’s most useful features is its seamless integration with Exchange, the backend system that handles all the features of Outlook including emails, appointments, and contacts.  This process facilitates numerous other features, which include tracking activities to relevant records, converting incoming emails to cases, and giving developers a trigger point that can be used to drive behavior.   

Exchange is quite robust and stable, but there are times when a configuration setting in Dynamics can affect Exchange’s ability to integrate properly.  In most cases this will just cause small blips in functionality that get resolved in future integration steps, but sometimes the problem can be more insidious as we identified with the email mailbox error above. 

The last point I mentioned earlier is where we’ll focus today, using incoming emails to trigger processes in Dynamics 365.  Incoming emails are automatically created as email mailbox messages in the system, like how cases or contacts are created.  This triggers a Create event, on which workflows, plugins, and other customizations can begin.  This is a very common event to use, both for background and real-time workflow applications, as tracking email mailbox messages can inform other chained processes like when to resolve cases. 

The Solution – Real-Time Workflow Management 

The core issue we found was that we had two workflows both running on the creation trigger for incoming emails.  This wouldn’t have been a problem if one or both had been asynchronous (running in the background), but both workflows were running synchronously (in real-time).  This caused something of a race condition, where the incoming email was being processed by two workflows simultaneously.  To its credit, Exchange was able to handle this in most cases, but some emails were slipping through the cracks and being severely delayed or were denied entry into Dynamics altogether.   

The resolution was ultimately rather straightforward: we combined the real-time workflows into a single real-time workflow, eliminating the conflict.  

Conclusion

Ultimately, this simple solution communicates a larger point; it’s important to avoid implementing multiple real-time workflows that run off the same trigger wherever possible, especially when integrating with external systems.  Dynamics can handle a lot of unusual requirements gracefully, but there are still times when we as developers and power users need to consider how our configurations are implemented behind the scenes.  Real-time workflows can start to feel like an infallible solution to many process challenges, but the takeaway from this topic is that it’s important to avoid letting them conflict wherever possible.