How to Publish Marketing Forms in Dynamics 365 Customer Insights – Journeys: A Practical Guide

You’ve built a beautiful marketing form in Dynamics 365 Customer Insights – Journeys. Now what? Getting that form in front of your audience is where many marketing teams hit an unexpected wall, because there isn’t just one way to publish a form. There are three. And they work very differently.

This guide breaks down three hosting option available for Customer Insights – Journeys (CI-J) forms, explains the trade-offs, and helps you pick the right approach for your situation.

Why Publishing Method Matters

Before we dive in: the publishing options in CI-J aren’t mutually exclusive. You can publish the same form in multiple places simultaneously. But the method you choose has real consequences for your domain, your web team, your analytics, and what’s possible from a personalization standpoint.

Let’s look at your three options.

Option 1: Standalone Page — The Fastest Path to Live

What it is: A standalone page is a dedicated, Microsoft-hosted URL that CI-J generates for your form automatically. No CMS, no developer, no custom domain and your form is live on Microsoft’s content delivery network (CDN).

How it works: Inside the CI-J form editor, after creating your form, you select the standalone page publishing option and click Create in the dialog. That’s it. Microsoft provisions a hosted page and hands you a URL you can share immediately.

Because the page is served from Microsoft’s CDN, it benefits from global caching, fast load times, and high availability.

The caching caveat: That CDN caching does come with one trade-off. If you edit your form after publishing, updates can take up to 10 minutes to appear on the live standalone page. During testing or development, you can force the page to bypass the cache by appending #d365mkt-nocache to the URL.

When to use it: Situations where your own domain isn’t a requirement. So probably never..So only use this option for testing the forms.

Limitations to know: The URL will be on a Microsoft domain not your brand’s domain. You can’t embed this page inside your existing website layout, and you have limited control over surrounding design elements like navigation or footers. If brand consistency across your website is non-negotiable, you’ll want the next option.

Option 2: JavaScript Embed — Forms on Your Terms

What it is: The JavaScript embed option generates a short code snippet that you paste into any webpage, your CMS, your company website, a React or Angular application, or a Power Pages site. CI-J renders the form inline, inside your existing page, on your domain.

How it works: After publishing your form, CI-J provides a JavaScript snippet containing your organization ID, form ID, and endpoint. Paste that snippet into your page’s HTML wherever you want the form to appear, and the form loads automatically when a visitor opens the page.

For single-page applications (SPAs) built on frameworks like React, the same approach applies, you’ll need to replace the form identifier (msdynmkt_marketingformid), the organization ID (organizationid), and the organization endpoint directly in the snippet. The Customer Insights – Journeys JavaScript API supports custom events and hooks, making it possible to extend and customize form behavior programmatically when needed.

A useful styling tip: set the form’s font to “inherit” inside the CI-J form designer. This allows the form to automatically pick up the typography from your website’s CSS.

Domain authentication is required: Unlike the standalone page, embedding a form on your own website requires you to first authenticate your domain in CI-J’s settings. This is a one-time setup step, but it does involve your IT or web team. Forms on unauthenticated domains will not render.

When to use it:

• Embedding forms inside your existing website pages, blog, or product pages
• React, Angular, Vue, or other SPA-based web applications
• Any scenario where you need the form to appear on your own domain
• When you want full CI-J analytics, visit tracking, and web tracking on your own site

What makes it the recommended approach: This is the method Microsoft (and also I) recommends for most scenarios. It preserves all core CI-J form capabilities, visit analytics, submission tracking, web behavioral tracking, journey triggers, and prefill support. It also gives you the most control over where and how the form appears. If there’s any doubt about which method to use, start here.

Option 3: Form Capture — Meeting Your Existing Forms Where They Are

What it is: Form capture is for one specific scenario: you have a form that already exists on your website, built in a CMS, a custom frontend, or a third-party tool and rebuilding it inside CI-J isn’t practical. Instead of recreating the form, you attach a CI-J capture script to your existing form so that every submission gets routed into Dynamics 365 as a contact or lead record.

How it works: In the CI-J form editor, you create a “shadow” form, a configuration that maps your existing form’s fields to D365 attributes. CI-J then generates a capture script. A developer embeds that script on the same page as your existing form. When a visitor submits, the capture script intercepts the submission and sends it to D365 in parallel with any other systems already connected to that form.

This means your form can simultaneously feed data into D365 and into another CRM, marketing automation platform, or ticketing system without changing your existing form logic or breaking any current integrations.

Domain authentication is required: Your domain must be authenticated in CI-J settings, just like the JavaScript embed option.

When to use it:

• Your existing form has complex custom logic that would be difficult to replicate in the CI-J editor
• The form needs to submit to multiple systems simultaneously (D365 plus another platform)
• Redesigning or replacing the current form is not an option for business or technical reasons

Critical limitations: Form capture is the most complex option in practice and comes with meaningful constraints:

• No visit analytics or web tracking. CI-J cannot track page visits or behavioral web data when using form capture.
• Redirects can break submission capture. If your page redirects immediately after form submission, the browser may cancel the capture API call before it completes.
• A matching CI-J form must exist. Even though visitors never see the CI-J form, you still need to create it in the editor to configure consent and field mappings.

Microsoft’s own documentation is clear on this point: recreate the form in CI-J and use the JavaScript embed wherever possible. Use form capture only when rebuilding is genuinely not feasible. I wouldn’t be as harsh as the documentation though, because I see the value of form captures. But for marketing teams that are not experienced with CI-J it is a complex solution. So I would only use this when there are users who understand how it works.

Feature Comparison at a Glance

How to Choose: A Quick Decision Guide

Start here: Does your form need to live on your own domain?

• No → Use the Standalone Page. It’s the fastest option and requires zero setup beyond creating the form itself.
• Yes, and it’s a new form → Use the JavaScript Embed. Authenticate your domain once, drop in the snippet, and you’re live with full analytics and personalization support.
• Yes, and you have an existing form you can’t replace → Use Form Capture. Map your fields carefully, and go in with realistic expectations around the analytics and prefill limitations.

In almost all new form scenarios, the JavaScript embed is the right call. It’s flexible, it works everywhere, it keeps all CI-J features intact, and it only requires minimal developer involvement for the one-time domain authentication.

Do you have questions, ideas or remarks? Feel free to get in touch.