Integrating Dynamics 365 with Mailchimp and SendGrid

Mailchimp and SendGrid get mentioned in the same breath and solve almost opposite problems. Mailchimp is a marketing platform: audiences, campaigns, templates designed by a marketer, and consent management. SendGrid is a delivery engine: an API that sends the email your system tells it to, at volume, with deliverability tooling. Dynamics 365 integrates with both, but for different reasons, and confusing the two leads to marketing emails sent from a transactional pipe with no unsubscribe link, or order confirmations built as Mailchimp campaigns.

Mailchimp: audience sync, not email sync

The integration people want is "keep the Mailchimp audience in step with Dynamics 365 contacts". The pattern that works:

• Dynamics 365 is the source of who exists. Contacts with a marketing consent flag and a valid email flow to a Mailchimp audience, with segment tags derived from Dynamics 365 fields (customer type, region, product interest).
• Mailchimp is the source of engagement and consent changes. Unsubscribes, bounces, and campaign opens flow back to Dynamics 365, at minimum as a consent field update and ideally as activity records for the sales team's benefit.
• Campaigns are designed and sent in Mailchimp. Nobody tries to trigger Mailchimp campaigns from Dynamics 365 workflows; that is not what Mailchimp is for.

Tooling: the Power Automate Mailchimp connector handles member add and update. Mailchimp's own marketplace has Dynamics 365 connectors from third parties that do the full bidirectional sync with field mapping and are usually worth their subscription for a marketing team that does not want to own flows. For large audiences, batch through the Mailchimp API rather than one flow run per contact.

The consent field is the one that must be right. An unsubscribe in Mailchimp that does not reach Dynamics 365, followed by a sales rep's bulk email from Dynamics 365, is a compliance incident. Sync that field both ways, promptly, and test it. See email templates and bulk email in Sales for what Dynamics 365 itself can send.

If the organisation is deciding whether to keep Mailchimp or move marketing onto Customer Insights - Journeys, the comparison with HubSpot applies in most respects; the trade-off is native Dataverse integration against a tool the marketing team already knows.

SendGrid: transactional email from your own logic

SendGrid is for email that a process sends: order confirmations, password resets on a portal, case update notifications, invoice delivery. Dynamics 365 can send these itself through its server-side sync or through Business Central's SMTP and Microsoft 365 email setup, and for modest volumes it should. SendGrid enters when volume is high, when deliverability tooling matters (dedicated IPs, domain authentication, bounce and spam handling), when the sending system is a portal or an Azure Function rather than Dynamics 365 itself, or when the mail must not go through the corporate Exchange tenant.

Patterns:

• Power Automate with the SendGrid connector. A flow on a Dataverse event calls SendGrid with a dynamic template ID and the merge data. Simple and fine for hundreds of emails a day.
• Azure Function calling the SendGrid API. For volume, for attachments generated on the fly, and for retries and logging that flows make awkward.
• Business Central through SMTP. SendGrid exposes an SMTP relay, and Business Central's email accounts feature can use it as an SMTP account, which routes document sending through SendGrid with no code. See email setup in Business Central.

Events back: SendGrid's event webhook reports delivered, bounced, opened. Receive it in an HTTP-triggered flow or function and write the status to the record. Bounces in particular should update the contact so that the next process does not send to a dead address.

Which system is the sender

Every email leaving on the organisation's behalf needs a decision about the sending domain and authentication (SPF, DKIM, DMARC). Mailchimp and SendGrid both need domain authentication configured, and if Dynamics 365 or Microsoft 365 also sends from the same domain, the DNS records must accommodate all of them. Deliverability failures traced to a missing DKIM record for a third sender are common. Our email deliverability guide covers the DNS side, and it applies regardless of which tool sends.

Activity tracking

Sales users want to see marketing and transactional emails on the contact timeline. For Mailchimp, campaign sends and opens can be written back as custom activities; keep them summarised, because one activity per open across a large audience will bloat Dataverse quickly. For SendGrid transactional mail, write one activity per email at most, and only for emails a human would care to see.

What breaks in practice

Consent drift, as above. Audience sync that creates Mailchimp members for contacts who never consented. Merge fields in a SendGrid template that were renamed in Dataverse. Bounce events that nobody consumes, so the same dead address is emailed monthly. DNS records that were correct for two senders and broke when the third was added.

Stability verdict

Both connectors are stable and both vendors' APIs are mature. The Mailchimp sync is stable when narrow (contacts and consent, both directions) and fragile when it tries to mirror engagement in detail. SendGrid via an Azure Function or SMTP relay is as stable as any transactional email pipe gets. The organisational instability is ownership: marketing owns Mailchimp, IT owns SendGrid, and the consent field sits between them.