## **How to integrate Microsoft Dynamics 365 CRM with Webflow**

**What is Microsoft Dynamics 365 CRM?**  Microsoft Dynamics 365 is a suite of business applications built on Microsoft Dataverse, and its customer-facing apps cover sales, customer service, field service and Customer Insights. The app a Webflow site actually touches is Customer Insights - Journeys, which Microsoft created by folding the former Dynamics 365 Marketing product into Customer Insights, as its own [Customer Insights FAQ](https://learn.microsoft.com/en-us/dynamics365/customer-insights/journeys/ci-faq) explains. That app owns the forms, the web tracking script and the journey triggers described below.

The connection points are narrower than the product surface suggests: an agent that reads and writes both systems over MCP, a form that drops a visitor into Dataverse as a lead or contact, a job that moves records between Dataverse and the CMS, and a tracking script that ties a page visit back to a known contact. Which of them you build depends far more on your Dynamics 365 licence and your appetite for developer work than on anything Webflow does.

One thing to settle before you start: Microsoft removed the outbound marketing module from all environments in May 2026 and deleted its documentation, per Microsoft’s own [outbound marketing removal](https://learn.microsoft.com/en-us/dynamics365/customer-insights/journeys/outbound-removal-notes) notes. Any Dynamics 365 form instruction you find that mentions outbound marketing, a "Go live" button or a "Form hosting" panel is describing software that is gone. The steps below use the real-time Customer Insights - Journeys interface.

### **Connect agents to both systems with MCP servers**

Both platforms now expose an MCP server, so an agent can read a CRM record and edit the site that record came from without you writing either API client. This is the fastest route for the ad hoc work that used to eat an afternoon: reconciling a partner directory against account records, or checking which landing page a batch of leads arrived on.

The [Webflow MCP server](https://developers.webflow.com/mcp/reference/overview) works inside your existing Webflow permissions and roles, and it covers CMS collections and items, page settings and SEO metadata, site and page custom code, assets, and forms, including reading a form’s schema and listing, updating or deleting its submissions. On the Microsoft side, Dataverse itself acts as an MCP server at `https://{dataverseOrgName}.crm.dynamics.com/api/mcp`, with tools to search data, run SELECT queries and create, update or delete rows. An admin has to enable the server and its allowed clients for the Power Platform environment first, which is documented on Microsoft’s [Dataverse MCP server](https://learn.microsoft.com/en-us/power-apps/maker/data-platform/data-platform-mcp) page.

Treat the two servers as separate authorizations rather than one pipe. Nothing in either product copies a Dataverse row into Webflow on its own, so an agent moving CRM data into a Collection is publishing that data to the open web the moment the site publishes. Decide which fields belong on a public page before you point an agent at a Collection, because a published CMS item is readable by anyone with the URL.

### **Embed Customer Insights - Journeys forms**

The no-code route is to build the form in Customer Insights - Journeys and drop its JavaScript into a Webflow page, which writes leads or contacts straight into Dataverse with no middleware in between. This needs a Dynamics 365 Customer Insights licence. Microsoft licenses it at tenant level rather than per seat, so it will not appear under Licenses in the Microsoft Admin Center, and a legacy Dynamics 365 Marketing licence entitles the Journeys half only. Microsoft’s [licensing guidance](https://learn.microsoft.com/en-us/dynamics365/customer-insights/journeys/license-setup) sets out how to check what your tenant holds.

#### **Embed a published form**

Design the form in Customer Insights - Journeys, select **Publish** in the top right, and choose **Embed to an external page using JavaScript**. Paste the generated snippet into a [Custom Code Embed element](https://help.webflow.com/hc/en-us/articles/33961332238611-Custom-code-embed) on the Webflow page where the form belongs. Microsoft’s [hosting options](https://learn.microsoft.com/en-us/dynamics365/customer-insights/journeys/real-time-marketing-deploy-pages) article covers the alternatives, including a standalone page on Microsoft’s CDN and hosting the form inside a single page application.

Before it renders anywhere, the domain has to be authorized. Microsoft’s [form creation guide](https://learn.microsoft.com/en-us/dynamics365/customer-insights/journeys/real-time-marketing-form-create) is blunt about the failure mode: "If the domain isn't allowed for external form hosting, the form isn't rendered on your web page and all form submissions are rejected." Authorize the domain first, through [domain authentication](https://learn.microsoft.com/en-us/dynamics365/customer-insights/journeys/domain-authentication), or you will debug a form that silently accepts nothing.

Four things are worth knowing before you commit to this method:

- **Submissions bypass Webflow entirely**: the form posts to Microsoft, so nothing lands in Site settings > Forms and no Webflow notification email goes out.
- **Prefilling needs the same domain authorization**: known contacts only get pre-populated fields once the hosting domain is authorized in Customer Insights - Journeys.
- **Submissions can start a journey**: the Marketing Form Submitted trigger fires on every submission, which is how follow-up email or SMS gets sent without any further wiring.
- **Styling lives in Microsoft’s editor**: you control the layout in the Customer Insights - Journeys form designer, not in Webflow, so brand changes happen in two places.

That last point is the usual reason teams reject this method and reach for form capture instead.

#### **Capture an existing Webflow form**

Form capture keeps the Webflow-designed form and routes its submissions into Dynamics 365 through a JavaScript snippet, so you keep full design control. It is genuinely more work than the embed, and Microsoft says so: its [form capture](https://learn.microsoft.com/en-us/dynamics365/customer-insights/journeys/real-time-marketing-form-capture) article states that form capture requires developer assistance, and recommends it only when your existing form carries logic you cannot rebuild or already posts to other systems.

The feature is off by default. An admin enables it under **Settings** \> **Feature switches** \> **Forms**. You then build a matching form in the Customer Insights - Journeys editor, publish it, and copy the form capture snippet, which arrives as a template with `***Please fill***` markers you have to replace. The mapping is declared in code, with `d365mktformcapture.waitForElement` to grab the form element and `serializeForm(form, mappings)` to map each Webflow field name onto a Dataverse attribute. Add it through [head and body tags](https://help.webflow.com/hc/en-us/articles/33961357265299-Custom-code-in-head-and-body-tags) so it loads on every page carrying that form.

Two limits that the method’s fans tend to leave out: a field only writes to the record if it also exists on the published Customer Insights - Journeys form, and consent settings are read from the form editor, not from the snippet, so editing consent in the code does nothing. Web tracking is also unavailable in form capture scenarios, and form visit events are not collected for analytics.

#### **Track known contacts with the web tracking script**

Customer Insights - Journeys can attribute page visits and link clicks on your Webflow site to CRM records, but only for people it already knows. Microsoft states the boundary plainly: "Any anonymous web interactions, such as visits, clicks, and anonymous web form traffic, aren't supported and aren't surfaced in the out-of-the-box analytics." So this is not an analytics replacement, and it will not tell you who your anonymous traffic is.

The script is generated under **Settings** \> **Web Tracking** in the Customer Engagement section, and Microsoft asks you to place it in the `<head>` tag, which in Webflow means Site settings > Custom code > Head code. For it to record anything, the visitor’s first arrival has to come through a Customer Insights - Journeys tracking link such as an email link, link tracking has to be on for that URL, and the contact needs Allow Tracking enabled. Microsoft’s [web tracking](https://learn.microsoft.com/en-us/dynamics365/customer-insights/journeys/interaction-journey-decision) documentation lists the full set of conditions.

The script also sets a cookie for every visitor, including visitors who used your own opt-out control, unless you modify the script to respect that control. Microsoft says this is your organization’s responsibility to get right in the markets where you operate, and it is a decision to make before the script ships, not after.

### **Automate with Zapier**

[Zapier](/content/integrations/zapier/index.html) is the shortest path from a Webflow form submission to a Dynamics 365 lead, and Microsoft Dynamics 365 CRM is one of the apps it already pairs with Webflow through prebuilt templates. The workflow builder handles OAuth and field mapping through dropdowns, so nobody has to touch the Dataverse Web API.

Build it by selecting **Webflow** and **Form Submission** as the trigger, then **Microsoft Dynamics 365 CRM** with **Create Lead** or **Create Contact** as the action, mapping the fields and testing with a real submission. On the Webflow side, add the connected App under Connected Apps in the form’s Settings panel rather than replacing the form action, so Webflow keeps storing the submission as well.

Four properties of this route shape what you can build on it:

- **Dynamics triggers poll, they do not push**: Zapier checks Dynamics 365 for new records on an interval rather than receiving a webhook, so CRM-to-Webflow updates arrive with a lag.
- **Two directions means two Zaps**: one Zap runs trigger to action in a single direction, so a round trip is two separate Zaps, not a sync engine with conflict resolution.
- **Custom fields are addressable**: the Dynamics 365 action can write to custom Dataverse columns, not only the stock lead and contact fields.
- **The CRM side is a paid app**: Zapier marks Microsoft Dynamics 365 CRM as a Premium app on the templates for this pairing, so check that your Zapier plan covers premium apps before you build on it.

If you need conflict handling or bulk record movement rather than one record at a time, look at Make or a direct API job instead.

### **Automate with Make**

[Make](/content/integrations/make/index.html) gives you a visual scenario builder with routing, error handling and multi-step data transformation, which is what you want once one Zap per direction stops being enough. One gate stands in the way first, though.

Make lists its [Dynamics 365 app](https://www.make.com/en/integrations/microsoft-dynamics-365-crm) as available only on its Enterprise plan, and the app ships seven modules: a Watch Records trigger, Create, Update, Delete, Get and Make an API Call actions, and a Search Records module. Make ships no instant webhook trigger on the Dynamics 365 side, so a scenario that reacts to CRM changes polls for them. The Webflow half is different: a Webflow form can push to Make the moment somebody submits.

To wire the Webflow side, select the form, open the Settings panel, click the add icon next to **Send to**, choose **Webhook**, paste the Make webhook URL and save. Webflow then shows a secret key exactly once, which you use to validate the request signature, so copy it before closing the dialog. Adding a webhook this way leaves the existing Webflow and Email notifications destinations in place, which is what you want.

### **Webflow webhooks and Power Automate**

If your organization already pays for Power Platform, Power Automate does the same job as Zapier or Make on licences you hold, with the flow living inside the same tenant as the CRM data. The Webflow form pushes to an HTTP endpoint and the flow writes the record.

The setup runs as follows:

1. Create a Power Automate flow with the **When an HTTP request is received** trigger.
2. Define a JSON schema that matches the payload your form sends.
3. Add the **Create a new record** action and point it at the Dynamics 365 table you want.
4. Map the incoming fields onto that table’s columns.
5. Copy the generated HTTP POST URL.

Back in Webflow, select the form, open the Settings panel, click the add icon next to **Send to**, choose **Webhook** and paste that URL. Use **Webhook** rather than **Custom action** here, for the reason in the next section.

### **Build with the Webflow and Dataverse APIs**

Most teams never need this tier, and reaching for it when a Zap would do is the commonest way these projects overrun. Write code when you need validation before a record is created, custom deduplication, or a write that fans out to more than one system.

Dynamics 365 records live in Dataverse and are reachable over the [Dataverse Web API](https://learn.microsoft.com/en-us/power-apps/developer/data-platform/webapi/overview), an OData v4 REST interface authenticated with OAuth 2.0. On the Webflow side the [Webflow Data API](https://developers.webflow.com/data/reference/rest-introduction) gives you CRUD access to Collections and their items, plus forms and submissions.

#### **Custom lead capture with server-side processing**

The pattern is to catch the submission at your own endpoint, do the work, then write to Dataverse. Point the Webflow form at your endpoint with a webhook under **Send to**, validate and transform the payload, authenticate with OAuth 2.0, create or update the record through the Dataverse Web API, and log failures so a rejected write is visible rather than silent.

Use a webhook rather than a custom action unless you have decided you do not want a copy in Webflow. Webflow’s [Webflow form settings](https://help.webflow.com/hc/en-us/articles/33961347548563-How-do-I-add-forms-in-Webflow) documentation is explicit: "When you set a custom action, submissions won’t be sent to or stored in Webflow." A custom action also cannot be combined with the Webflow or Email notifications destinations, so choosing it means giving up the submission archive and the notification email at the same time. A webhook keeps both.

Keep the heavy work outside Dataverse. A Dataverse message operation has to finish within two minutes, and that budget covers the operation plus every synchronous and asynchronous plug-in registered against it, per Microsoft’s [Dataverse performance guidance](https://learn.microsoft.com/en-us/power-apps/developer/data-platform/analyze-performance). Long-running enrichment belongs in your own service or an Azure Function, not in a plug-in on the create message.

#### **Sync Webflow CMS with Dynamics 365 records**

Pulling Dataverse rows into [Webflow CMS](/content/cms/index.html) is how partner directories, customer case studies and team pages stay current without anybody retyping them. Be deliberate about it, because a Collection item is public once the site publishes, so a field you would not print on a poster does not belong in a Collection.

One-way, Dataverse to Webflow, is the version worth building first: read the rows you want, map them onto Collection fields, and create or update items through the Data API. Two-way needs you to decide which system wins when both change, and nothing in either product decides that for you. For anything at volume, batch the job on a schedule rather than reacting to every record change, and watch your rate limits on both sides. If a Collection page needs record-specific markup, [custom code in CMS](https://help.webflow.com/hc/en-us/articles/33961236623635-Custom-code-in-the-CMS) lets you inject it per item.

Whichever direction you build, the same questions decide the design: which system is authoritative for each field, what happens to a Collection item whose source record is deleted, how a failed write gets surfaced, and who sees the data once it is published. Settle those before writing the job, because retrofitting them means republishing the site.

## **What you can build**

Once records move in both directions, a Webflow site stops being a brochure in front of the CRM and starts being one of its surfaces. These are the builds that hold up in practice.

- **Lead capture that routes itself**: a Webflow form writes straight into Dataverse as a lead, and a Customer Insights - Journeys trigger sends the follow-up and assigns the owner.
- **Partner and customer directories**: account records become Collection items on a schedule, so the public directory reflects the CRM rather than a spreadsheet somebody forgot.
- **Known-contact personalization**: visitors who arrive through a tracking link get content matched to their record, with anonymous traffic served the default experience.
- **Progressive profiling forms**: an embedded Customer Insights - Journeys form prefills what the CRM already knows on an authorized domain and asks only for what is missing.

Build a [marketing automation hub](/content/blog/webflow-zapier-marketing-automation-hub/index.html) to connect these workflows across the rest of your stack.

## Frequently asked questions

- **How do I connect Webflow forms to Microsoft Dynamics 365 CRM without coding?**  Use Zapier or Make: set Webflow Form Submission as the trigger, Create Lead or Create Contact as the action, and map the fields. Alternatively, embed a published Customer Insights - Journeys form on an authorized domain.

- **How do I troubleshoot failed form submissions between Webflow and Microsoft Dynamics 365?**  Check the run history in Zapier or Make first, since most failures are authentication, a data type mismatch or a required Dataverse column left empty. For an embedded Dynamics 365 form, confirm the hosting domain is authorized: an unauthorized domain rejects every submission.

- **Can I sync Dynamics 365 data to Webflow CMS collections?**  Yes. Read the records over the Dataverse Web API and write them to Collections with the Webflow Data API, or let Zapier or Make move them. Two-way sync needs you to define which system wins on conflict. Remember that a published Collection item is publicly readable.

- **How do I add custom code to my Webflow site for Microsoft Dynamics 365 integration?**  Use a Custom Code Embed element for a form on one page, Site settings > Custom code for the site-wide web tracking script, and custom code in the CMS for markup that varies per Collection item. The Head code and Footer code sections hold 50,000 characters each.

- **Do my form submissions still get stored in Webflow if I send them to Dynamics 365?**  It depends which destination you pick. A webhook or a connected App runs alongside Webflow storage and notification emails, so you keep a copy. A custom action does not: it bypasses Webflow form processing entirely, and it cannot be combined with the Webflow or Email notifications destinations.