Tracking Customer Email in Dynamics 365 When IT Will Not Enable Server-Side Sync

If IT will not enable server-side synchronization, split the request into the two problems you actually have. Proving historical correspondence for an audit next month does not need Dynamics 365 at all: a Microsoft Purview eDiscovery search across the relevant mailboxes, exported with its report, is the fastest defensible route. Capturing correspondence from now on needs a shared mailbox that customer email reaches, plus a Power Automate flow that creates email activities against the matching contact, lead or account, with record-matching rules that refuse to guess and deduplication on the internet message ID. You lose per-user automatic tracking, the Outlook add-in and anything that never reaches the shared mailbox, so say that plainly before anyone relies on it.

Why does email tracking in Dynamics 365 depend on server-side synchronization?

Because server-side synchronization is the component that connects Dynamics 365 to Exchange Online mailboxes. It reads incoming mail for users whose mailboxes are configured and approved, creates email activities according to each user's tracking option, sends email from Dynamics 365 through Exchange, and synchronises appointments, contacts and tasks where that is switched on. The Dynamics 365 App for Outlook, which gives sellers the Track and Set Regarding buttons inside Outlook, also requires server-side synchronization. It is not a workaround for a refusal: if the mailbox is not enabled for server-side sync, the add-in cannot track.

IT teams usually have a specific reason for refusing, and it is worth writing down. Common ones are that mailbox approval gives the Dynamics 365 service access to user mailboxes, that personal and sensitive email could be copied into a business application, that the security review for the application has not been done, or that data residency and retention for email held in Dataverse have not been agreed. Each of those has a different answer, and some of them apply to the workaround too.

What are the two problems behind "we need to see customer emails in Dynamics"?

• The historical problem: an auditor, a regulator, a dispute or an internal investigation needs evidence of what was sent to and received from a customer over a past period, usually by a fixed date.
• The ongoing problem: sellers and service agents need customer correspondence visible on the record from now on, so a colleague can pick up an account without asking for forwarded threads.

Mixing them causes the delay. Teams try to backfill years of email into Dynamics 365 to satisfy an audit, which is slow, lossy and not what an auditor asked for. Handle the audit from the mail system where the evidence already lives, and design the ongoing capture separately.

How do you produce historical correspondence for an audit without Dynamics 365?

Use the eDiscovery capability in the Microsoft Purview portal. It searches Exchange Online mailboxes where the messages already are, and it keeps a record of what was searched, by whom and when. Someone with the eDiscovery roles, usually in compliance or IT, runs it, which is often easier to agree than server-side sync because it is a one-off, scoped, logged action.

1. Agree the scope in writing with whoever asked for the evidence: which customers or domains, which mailboxes, which date range, and whether shared mailboxes, archives and mailboxes of people who have left are included.
2. Create an eDiscovery case so the search, any hold and the export sit under one audited container.
3. Search by participant, such as the customer's email domain in sender and recipient fields, plus the date range, across the agreed mailboxes. Review the statistics and a sample before exporting.
4. Export the results in the format the reviewer can open, typically individual messages or a PST, and keep the export summary and manifest that come with it.
5. Hand over the export with a short note of the search criteria, the mailboxes covered, the date and who ran it, so the evidence explains its own completeness.

Two limits matter. eDiscovery can only find what Exchange still holds, so mail deleted and purged before any retention policy or hold applied may be gone, and a departed employee's mailbox is only searchable if it was retained as an inactive mailbox or otherwise preserved. Which eDiscovery features, export formats and roles are available depends on your Microsoft 365 licences and on changes Microsoft is making to the Purview eDiscovery experience, so check current Microsoft documentation before promising a format or a date. If the audit also asks who changed CRM records, that is a separate trail, covered in our guide to Dynamics 365 audit trails that survive a regulator.

How do you capture customer email going forward without server-side sync?

Route the email into one shared mailbox and let a flow turn each message into a Dataverse email activity. The flow runs under a dedicated service account that has access to that one mailbox, not to user mailboxes, which is usually the point on which IT agrees.

1. Create a shared mailbox for customer correspondence and grant the service account access to it only.
2. Decide how email reaches it: sellers add the mailbox as a Bcc or forward a thread, or an Exchange administrator adds a mail flow rule that copies messages to and from agreed customer domains into it. A rule captures more reliably than people remembering, but it is a policy decision for IT and privacy, not a technical detail.
3. Build a Power Automate cloud flow triggered when a new email arrives in the shared mailbox, using the Office 365 Outlook connector, in a solution with connection references so it moves between environments properly.
4. Read the internet message ID from the trigger and check Dataverse for an existing email activity with that message ID before doing anything else.
5. Match the sender and recipients to contacts, leads and accounts using the rules below.
6. Create the email activity with subject, body, direction, the sender and recipients as activity parties, the regarding record where one is unambiguous, and the message ID stored.
7. Mark the activity as received or sent rather than leaving it as a draft, and add attachments only if the policy agreed below says so.
8. Send unmatched and ambiguous messages to a review queue, and alert someone when the flow fails instead of letting runs fail silently.

The flow design, error handling and connection governance are the kind of work our Power Automate consulting service delivers, so this post stays on the rules that make the result trustworthy.

Which record-matching rules stop the flow creating garbage?

The failure mode of every email capture flow is confident wrong matching: an email attached to the wrong contact is worse than an email not attached at all, because nobody knows to distrust it. Write the rules down and make the flow follow them.

• Match on the full email address against the email columns of active contacts first, then active leads, never on display name.
• Exactly one match links the activity. Zero matches or more than one match goes to the review queue with the candidates listed, rather than picking the first or the most recent.
• Ignore your own domain when matching, so an internal colleague on copy is never treated as the customer.
• Do not match on free email domains, and only match on company domain to an account where the domain belongs to one account and the rule has been agreed.
• Set the regarding record only when it is certain: a single matched contact, or a case or opportunity reference found in the subject in a format you control. Otherwise record the parties and leave regarding empty for a person to set.
• Exclude messages marked private or confidential, auto-replies, bounces and newsletters by header and sender rules before matching.
• Treat forwarded messages differently. A forward is a new message sent by your colleague, so the customer is inside the quoted body rather than in the sender field. Prefer Bcc or a mail flow rule, and send forwards to review unless the flow can reliably read the original sender.
• Log every decision the flow made, so a wrong link can be traced to the rule that produced it.

If your contact data already holds duplicate people with the same address, fix that first, because no matching rule survives it. Our guide to duplicate data cleanup in Dynamics 365 covers the approach.

How do you stop the same email being recorded twice?

Treat the internet message ID as the identity of the email. Every message carries one, the copy in a seller's sent items and the copy delivered to the shared mailbox carry the same one, and the Dataverse email activity has a column to hold it.

• Before creating, query for an existing email activity with that message ID. If one exists, add any missing parties or regarding link to it instead of creating a second activity.
• Set the flow trigger to run one message at a time, or build a guard against two runs processing the same message at once, because a thread copied in by two people can arrive seconds apart.
• Keep the conversation ID from the trigger in a column of its own if you want to group a thread, since without server-side sync you do not get the tracking token threading that Dynamics 365 uses for correspondence it tracks itself.
• Never delete and recreate activities to correct a match. Update the existing one, so the history of the activity stays intact.

What do you lose compared with proper server-side synchronization?

Be explicit, in writing, with the sales and service leaders before go-live:

• No per-user automatic tracking. Nothing is captured unless it reaches the shared mailbox, so a seller who replies from a phone without the Bcc leaves a gap, and a mail flow rule only covers the domains and directions it names.
• No Track or Set Regarding buttons in Outlook, because the Dynamics 365 App for Outlook needs server-side synchronization. Linking to a specific opportunity or case happens in Dynamics 365, not in Outlook.
• No sending email from Dynamics 365 through Exchange, and no appointment, contact or task synchronisation.
• Sent items from personal mailboxes are only captured if they were copied to the shared mailbox at the time. They cannot be pulled afterwards without the same mailbox access IT refused.
• Attachments are a choice, not a default. Storing them uses Dataverse file capacity and copies potentially sensitive documents into the CRM, so many teams store the message only, or attachments below an agreed size and type.
• Threading, Copilot and sales features that rely on synchronised mailboxes will be weaker or unavailable. Check current Microsoft documentation for which features depend on server-side synchronization before promising them.

Which security and data residency questions will IT still ask?

The same ones, and they deserve answers rather than enthusiasm. Email copied into Dataverse is stored in the region of the Dynamics 365 environment, is visible to anyone whose security role can read email activities for that record, and falls under your CRM retention and data subject request process, not only under the mailbox retention policy. Agree who can read captured email, whether some teams should see activity records but not bodies, how long captured email is kept, and how it is erased on request. Keep the service account out of interactive sign-in, protect its connection with the same controls as any privileged account, and include the flow in your data loss prevention policy.

Also record why this is not a permanent substitute. The shared mailbox pattern is a sound interim or a sound answer for a narrow scope, such as one team with a small set of customer domains. If the business needs full correspondence tracking for every seller, the better conversation with IT is usually about scoping server-side sync to named mailboxes, with the controls they asked for, rather than growing a workaround forever.

Which platform should hold customer correspondence if Microsoft licensing is part of the blocker?

Sometimes the refusal is really about cost or control: licensing every person who touches customer email, or keeping email in a system your own team hosts. In that case the question is wider than email tracking, and the honest answer may be Dynamics 365 with properly scoped synchronisation, Power Platform, or a custom-built CRM on React, Node.js, PostgreSQL or .NET that reads mail through the channel your IT team approves and runs without per-user Microsoft licences.

How does Solzet help track customer email when server-side sync is off the table?

We start by separating the audit from the ongoing capture, help your compliance or IT team scope the eDiscovery export, then design and build the shared mailbox flow with written matching, deduplication and attachment rules, a review queue and monitoring. Where Dynamics 365 Sales is being implemented or reworked at the same time, our Dynamics 365 Sales service covers the Outlook and email configuration once synchronisation is approved. Our senior consultants and full-stack developers bring 8+ years of Dynamics 365 Customer Engagement, Power Platform and custom CRM delivery, working remotely from Yerevan, Armenia, directly or white-label for Microsoft partners.