Forms and Landing Pages in Salesforce Marketing Cloud Next

For more than a decade, every signup form, landing page and preference center in Salesforce Marketing Cloud has run through CloudPages, AMPscript and a healthy amount of custom code. The Summer '26 release of Marketing Cloud Next changes that: forms, landing pages and preference pages are now native platform objects you can personalize without writing a line of SSJS. Here is how to rebuild your acquisition and consent stack on those new primitives, what you actually gain, and what still belongs in Engagement.

What Summer '26 actually changes

Three shifts matter for teams running SFMC day to day.

Forms became campaign components

Building an acquisition campaign in Marketing Cloud Next used to mean picking the "Signup Form" flow and configuring every step by hand: page, fields, mapping, confirmation. Flow templates now do that work for you. You start from a template, adjust the fields, and the mapping into your Marketing Objects is already wired.

Landing pages support preconfigured dynamic content

Landing page templates now accept rule-based dynamic content and cross-object merge fields. A single variation can be synchronized across several components of the page, so the hero banner, the headline and the form all react to the same segmentation rule instead of drifting apart over time.

Custom fonts landed in Content Builder

You can upload your brand web fonts and use them across emails, landing pages, forms and templates, with fallback fonts defined per business unit. No more shipping headline text as flattened images just to stay on brand.

Step 1 — Build a native form

Start from the acquisition flow template rather than a blank page. Mapping logic is declared at the form level, not buried in the page code. A properly configured lead capture form writes straight into a Marketing Object:

{
  "formName": "Newsletter_EN_2026",
  "targetObject": "Contact__mo",
  "fields": [
    { "name": "email",      "mapTo": "Email__c",         "required": true },
    { "name": "firstName",  "mapTo": "FirstName__c",     "required": false },
    { "name": "segment",    "mapTo": "Interest__c",      "type": "picklist" },
    { "name": "optInEmail", "mapTo": "Consent_Email__c", "type": "boolean" }
  ],
  "consentModel": "explicit",
  "onSubmit": { "action": "triggerFlow", "flowId": "welcome_en_v2" }
}

One thing to get right from day one: declare consent as a real form field, not a checkbox pre-ticked in the template. That field is what feeds consent mapping back into Engagement, and it is the record your legal team will ask for when a subscriber disputes an opt-in.

Step 2 — Personalize the page with Handlebars

Marketing Cloud Next landing pages run on Handlebars, not AMPscript. The mental shift is real: you stop manipulating imperative variables and start describing a render against a data context. A typical personalization block:

<section class="hero">
  {{#if contact.FirstName__c}}
    <h2>Hi {{contact.FirstName__c}}, your picks are ready</h2>
  {{else}}
    <h2>Your personalized picks are ready</h2>
  {{/if}}

  {{#each recommendations as |item|}}
    <article>
      <h3>{{item.title}}</h3>
      <p>{{formatCurrency item.price "USD" locale="en-US"}}</p>
    </article>
  {{/each}}
</section>

Compare that with the AMPscript equivalent your team is almost certainly still maintaining on a CloudPage somewhere:

%%[
  SET @first = AttributeValue("FirstName")
  IF NOT EMPTY(@first) THEN
    SET @headline = Concat("Hi ", @first, ", your picks are ready")
  ELSE
    SET @headline = "Your personalized picks are ready"
  ENDIF
]%%
<h2>%%=v(@headline)=%%</h2>

The Handlebars version is shorter, but the real win is that it is declarative and testable. Render the same template against a fixture JSON context and you get a verifiable output, which finally makes regression testing on landing pages a realistic practice rather than a nice idea.

Step 3 — A preference center without CloudPages

This is where the payoff is biggest. Custom preference pages have been native objects since Spring '26, and Summer '26 adds SMS and WhatsApp consent mapping, rolling out gradually through August 17, 2026.

The preference schema is declared once and serves both the page and your targeting decisions:

{
  "preferenceCenter": "prefs_en",
  "channels": [
    { "key": "email_promo", "label": "Offers and promotions", "default": false },
    { "key": "email_news",  "label": "Product news",          "default": false },
    { "key": "sms",         "label": "Transactional SMS",     "default": false },
    { "key": "whatsapp",    "label": "WhatsApp",              "default": false }
  ],
  "globalOptOut": { "key": "unsubscribe_all", "honorsChannelLevel": true },
  "auditTrail": true
}

Two rules are non-negotiable here. First, turn on the audit trail: without a timestamp on every preference change, your proof of consent is worth nothing in a dispute. Second, confirm that globalOptOut genuinely respects channel-level granularity. A global unsubscribe that silently wipes SMS consent is a compliance incident, not an implementation detail.

The real saving is not the hours you spend building a landing page. It is the maintenance debt. Every AMPscript CloudPage you do not create in 2026 is an asset nobody has to debug in 2029, long after its author has left the company.

Step 4 — What stays in Engagement

Do not declare victory too early. Several use cases still justify CloudPages and AMPscript:

Pages that read directly from a Data Extension through SSJS
Integrations that accept an external POST and process it server side
Legacy unsubscribe pages referenced in emails you have already sent
Multi-page microsites with complex conditional routing

The dividing line is simple: anything that is data capture or preference management moves to Next. Anything that is application logic stays in Engagement for now.

A four-week migration plan

Week 1: inventory your live CloudPages and sort them into three buckets — form, preference, application. Week 2: rebuild your highest-traffic signup form natively and run both versions in parallel. Week 3: migrate the preference center, keeping the old URL alive as a 301 redirect. Week 4: compare completion rate and page load time across both versions before committing to the full cutover.

Key takeaways

Forms are native now. Start from an acquisition flow template rather than a blank page, because the mapping into your Marketing Objects is already wired.

Handlebars replaces AMPscript on pages. Templates become declarative and testable against a JSON context, which makes real regression testing possible.

The preference center is the priority project. That is where AMPscript debt is heaviest and compliance risk is highest.

Enable the audit trail on day one. Consent without a timestamp is not defensible evidence when someone challenges an opt-in.

CloudPages is not going away. Keep application logic and server-side integrations there, and migrate only capture and preferences.

Planning your CloudPages migration to Marketing Cloud Next and want the consent side handled properly? Let's talk through your SFMC setup.