Troubleshooting Microsoft Dataverse: Email Sync Issues and Data Discrepancies

Table of Contents

This article provides comprehensive troubleshooting information for common incoming email synchronization issues encountered when utilizing server-side synchronization within Microsoft Dataverse. Understanding these scenarios and their underlying causes is crucial for maintaining accurate and efficient email processing within your Dataverse environment. We will explore unexpected email tracking, duplicate entries, synchronization of old emails, and issues with sender/recipient party resolution.

Incoming Emails Are Unexpectedly Tracked or Synchronized¶

One frequent issue involves emails being tracked or synchronized into Dataverse when seemingly they should not be. This can lead to clutter in user activities or unexpected processing by system components like queues. Identifying the root cause requires understanding how Dataverse resolves email recipients and applies tracking rules.

Symptoms¶

A typical symptom is an email addressed to a single recipient in an external system, such as Microsoft Exchange, appearing in Dataverse as tracked against multiple records. For instance, an email sent to paul.cannon@example.com might be resolved and tracked for both a user record named “Paul Cannon” and a queue record named “Paul Cannon’s Queue” if both share that email address in Dataverse.

In such a scenario, the email might be automatically accepted and processed by the queue, especially if the queue’s incoming email settings are configured to accept “All email messages.” This can occur even if the individual user’s personal options are set to “No email messages” or a more restrictive filter. This discrepancy highlights the importance of reviewing configuration settings for all entities sharing an email address.

Cause¶

Server-side synchronization determines whether to automatically track emails based on the configured incoming email filtering method for each identified Dataverse recipient. A Dataverse recipient is identified by searching for user and queue mailboxes associated with the email addresses listed in the To, Cc, and Bcc fields of the received email. If an email address matches multiple mailboxes in Dataverse, each mailbox’s filtering settings are evaluated independently.

Consequently, if an email address corresponds to more than one Dataverse mailbox, and one of those mailboxes is configured to automatically track the email based on its filtering method, the email will be synchronized. This can result in unexpected tracking if one entity (like a queue set to track everything) overrides the intended behavior for another entity (like a user set not to track certain emails). Examining the To, Cc, and Bcc fields on the tracked email record in Dataverse can reveal which Dataverse entities were resolved as recipients.

Resolution¶

To resolve unexpectedly synchronized emails, the first step is to pinpoint which Dataverse mailbox caused the automatic tracking. This can be done by examining specific properties of the synchronized email record within Dataverse. Two key fields provide insight into the tracking process:

• Accepting Entity: This field indicates the user or queue entity whose incoming email configuration led to the automatic tracking of the email. If a queue named “Support Queue” is configured to track all emails and receives a message, the “Support Queue” would be the Accepting Entity. This field is particularly useful for identifying the specific record whose settings governed the tracking decision.
• Receiving Mailbox: This field specifies the mailbox record that was actively processed by server-side synchronization when it detected that an email contained a recipient configured for automatic tracking. It’s important to note that the Receiving Mailbox is not always the same as the Accepting Entity. For example, if an email is sent to both User A (set to track replies) and Queue B (set to track all emails), and server-side synchronization processes User A’s mailbox first, User A’s mailbox might be the Receiving Mailbox, even though Queue B (configured to track all) is the Accepting Entity that ultimately caused the email to be tracked.

Manually tracked emails, which are initiated by a user action (like clicking the “Track” button in Outlook), will typically have an empty Accepting Entity field. In these cases, the Created by column on the email activity record in Dataverse will indicate the user who manually tracked the email.

Once the Accepting Entity is identified using these fields, you can navigate to that specific user or queue record’s mailbox settings. Adjusting the incoming email filtering method for that entity will prevent future emails from being automatically tracked based on its configuration. Common filtering options include tracking all emails, tracking only emails related to Dataverse records, tracking only replies to tracked emails, or tracking no emails. Selecting the appropriate setting ensures that only desired emails are synchronized. Detailed guidance on configuring these personal and queue mailbox options is available in the Dataverse documentation.

Duplicate Emails Are Tracked or Synchronized¶

Another common issue involves the creation of duplicate email records in Dataverse for a single email message. This can lead to inflated activity counts and confusion. While server-side synchronization generally aims to avoid duplicates, specific configurations can lead to this behavior.

Server-side synchronization can be configured to create separate activity records for both the “sent” and “received” copy of an email when it is exchanged between two Dataverse users. This behavior is controlled by a specific system setting. If this setting is enabled and both users involved have incoming email filtering methods that qualify the email for tracking, two distinct email activity records (one for the sender, one for the receiver) can be created in Dataverse for a single email exchange.

To prevent duplicate emails from being tracked or synchronized in this specific scenario (emails between Dataverse users):

1. Access the Dataverse environment settings. This is typically done by selecting the gear icon (⚙️) in the top-right corner and choosing Advanced Settings.
2. Navigate to Settings > Email Configuration > Email Configuration Settings.
3. Locate the setting labeled Set tracking options for emails between Microsoft Dynamics 365 users. Within this section, you will find the option Track emails sent between Dynamics 365 users as two activities.
4. Ensure this option is unchecked (cleared).

Clearing this checkbox tells the system to track an email exchanged between two Dataverse users as a single activity, rather than creating separate sent and received copies. This is a key setting for environments where duplicate tracking between users is a concern.

The system uses correlation logic and incoming email filtering methods to determine whether an email should be automatically promoted into Dataverse. Even with the “track as two activities” setting disabled, duplicate emails can still sometimes arise in more complex scenarios, particularly those involving queue mailboxes.

More Scenarios¶

While the primary setting addresses user-to-user emails, duplicates might still occur when queues are involved as either the sender or a recipient. This happens because queue mailboxes also have their own incoming email configurations, and their interaction with user mailboxes needs specific handling.

These scenarios include:

1. An email sent from a Dataverse queue to a user: If an email originates from a queue mailbox within Dataverse and is sent to a user whose incoming email settings qualify the email for tracking, a duplicate might occur. One copy could be the “sent” copy associated with the queue, and another could be the “received” copy associated with the user. To prevent the user’s mailbox from tracking this internal communication originating from a queue, a specific database setting needs to be enabled. The relevant setting is IgnoreInternalEmailFromQueues. Enabling this tells the system to ignore emails sent from internal Dataverse queues when evaluating a user’s incoming email tracking rules.

2. An email sent from a Dataverse user to a queue mailbox: Conversely, if an email is sent from a user mailbox within Dataverse to a queue mailbox, and the queue’s incoming email settings qualify the email for tracking (e.g., set to track all emails), a duplicate might be created. One copy could be the “sent” copy associated with the user, and another could be the “received” copy associated with the queue. To prevent the queue from tracking this internal communication originating from a user, another specific database setting needs to be disabled. The relevant setting is DoNotIgnoreInternalEmailToQueues. Disabling this setting tells the system to ignore emails sent to internal Dataverse queues when evaluating the queue’s incoming email tracking rules. Effectively, it makes the system ignore internal emails to queues.

These specific scenarios involving queues require adjustments to environment-level database settings, often referred to as OrgDBOrgSettings. These settings are not available through the standard user interface and require administrative actions, often involving command-line tools or specific administration interfaces. Changing these settings impacts the entire environment and should be done with care and understanding of their implications. Consulting the official documentation on managing environment database settings is recommended before making changes. There are numerous OrgDBOrgSettings that affect server-side synchronization behavior, and understanding their default values and potential impact is crucial for effective troubleshooting.

Old, Past, or Historic Emails Are Unexpectedly Tracked or Synchronized¶

Sometimes, users or administrators notice that very old emails, perhaps dating back months or even years, are unexpectedly synchronized into Dataverse after enabling or reconfiguring a mailbox. This behavior is governed by a specific date setting within the mailbox and email server profile configurations.

Server-side synchronization uses the Process Email From date (internally known as ProcessEmailsReceivedAfter) stored on each mailbox record to determine the earliest date from which emails should be considered for processing and tracking. When a mailbox is initially configured, tested, and enabled for the first time, this Process Email From date is typically initialized. The system usually defaults to using the date specified on the associated Email Server Profile record. The email server profile acts as a template, providing default settings for mailboxes connected to it, including the starting date for processing.

If you test and enable a mailbox, and it starts processing emails from a much older date than expected, this date likely originated from the associated email server profile. However, the Process Email From date is also maintained and updated on the individual mailbox record itself. After the initial processing cycle, the system usually updates this date on the mailbox record to reflect the date of the most recently processed email, ensuring that subsequent sync cycles only look for newer emails.

If a mailbox was previously disabled or configured incorrectly and then re-enabled, its Process Email From date might be older than desired. To prevent synchronization of historic emails in such cases, you can directly update the Process Email From date on the specific mailbox record. This attribute is not visible by default on the standard mailbox form but can be added through form customization. Once added, you can manually set this date to a more recent value, such as the current date or the date you wish to start tracking emails from. This change will take effect during the mailbox’s next synchronization cycle.

It is important to remember that the system prioritizes the more recent date when comparing the Process Email From value on the email server profile and the individual mailbox record. For instance, if the profile is set to process emails from January 1^st, 2023, but the mailbox record is manually set to March 1^st, 2023, the system will use March 1^st, 2023, as the starting point for that specific mailbox. Conversely, if the mailbox date is older than the profile date, the profile date will be used. Understanding this hierarchy is key to controlling how far back Dataverse looks for emails to synchronize.

Synchronized Emails Contain Unexpected Sender or Recipient Parties¶

When an email is synchronized into Dataverse, server-side synchronization performs a crucial step called email address resolution. This process involves examining the email addresses in the To, Cc, Bcc, and From fields of the incoming email and attempting to match them against records in Dataverse that have those email addresses.

For each email address found in the recipient fields (To, Cc, Bcc), the system queries Dataverse for any records (such as users, queues, contacts, leads, accounts, etc.) that have a matching primary email address. If one or more records are found for a single email address, all matching records are associated with the email activity as an activity party. Activity parties represent the various recipients and senders involved in an activity like an email.

As a direct result of this resolution process, if a single email address is associated with multiple active records in Dataverse (e.g., the same email address is used for a user and a queue, or perhaps a contact and a lead), all those resolved records will appear in the corresponding recipient fields (To, Cc, or Bcc) on the email activity record in Dataverse. Even if the original email in Exchange only listed the email address once, Dataverse will list all resolved entities. For example, if support@example.com is the email address for both the “Support User” and the “Customer Support Queue,” an email sent to support@example.com will show both the “Support User” and the “Customer Support Queue” as recipients on the synchronized Dataverse email activity.

This behavior is by design and reflects all entities within Dataverse that the system identified as recipients based on the email address. It’s important to distinguish this from duplicate email activities; this scenario involves a single email activity record correctly linked to multiple recipient parties.

Conversely, if an email address in the To, Cc, or Bcc field of an incoming email does not match any active record with a primary email address in Dataverse, that email address will still appear on the Dataverse email activity, but it will be displayed as an unresolved value, often just the raw email address string without a link to a specific Dataverse record.

Sender Resolution Order¶

Unlike recipient fields where multiple parties can be listed for one email address, an email activity in Dataverse can only have a single sender party. When the email address in the “From” field of an incoming email is associated with more than one active record in Dataverse, the system must decide which single record will be designated as the sender activity party. Dataverse utilizes a specific priority order to resolve the sender when multiple matches are found.

The priority order typically follows a hierarchy, prioritizing certain entity types over others. While the exact order can sometimes be influenced by specific environment configurations or updates, a common pattern is for the system to prioritize User records, then Queue records, and then potentially other activity party enabled entities like Contacts or Accounts. If an email address matches both a User and a Queue, the User record might be chosen as the sender. Understanding this resolution order helps explain why a specific record is listed as the sender when multiple potential matches exist in Dataverse for the sender’s email address.

Synchronized Emails Have Unexpected Owners¶

Beyond sender and recipient parties, another common discrepancy involves the ownership of the synchronized email activity record itself. The owner of an email activity in Dataverse determines which user or team has primary responsibility or visibility over that activity, depending on sharing and security configurations.

The ownership of an automatically tracked email activity is not arbitrary. It is typically assigned based on which mailbox’s configuration caused the email to be tracked. If an email is automatically tracked because a specific user’s incoming email filtering method matched, that user will usually become the owner of the resulting email activity record in Dataverse. Similarly, if an email is automatically tracked because it was directed to a queue configured to track all emails, the queue’s owner (which can be a user or a team) or the queue itself (depending on configuration and ownership type) might become the owner of the email activity.

In scenarios where multiple mailboxes associated with an email address qualify the email for tracking, the system determines the Accepting Entity (as discussed earlier) and often assigns ownership based on this entity or the Receiving Mailbox that processed the email. Understanding the relationship between the Accepting Entity, Receiving Mailbox, and the resulting ownership is key to predicting and troubleshooting ownership issues.

If an email is manually tracked by a user (e.g., using the Dynamics 365 App for Outlook), the user who performs the manual tracking action will typically be set as the owner of the email activity record.

Unexpected ownership can arise when the configuration leading to automatic tracking is not fully understood or when multiple entities sharing an email address have conflicting configurations. Reviewing the Accepting Entity, Receiving Mailbox, and the configuration settings of the mailboxes involved is essential to understanding why a particular record ended up owning the synchronized email.

These troubleshooting steps and explanations cover some of the most frequent issues encountered with incoming email synchronization in Microsoft Dataverse. By understanding how server-side synchronization resolves recipients, applies filtering rules, manages historical data, and determines ownership, administrators and users can more effectively diagnose and resolve unexpected behaviors. Proper configuration of user and queue mailbox settings, along with awareness of environment-level controls like database settings, is fundamental to ensuring accurate and predictable email synchronization.

Do you have further questions about these troubleshooting steps or encounter scenarios not covered here? Share your experiences and questions in the comments below.