Review Custom HTML Forms Before They Feed Email Automation

A custom HTML form is not finished when it looks correct. It is finished when a submitted value, consent decision, and event can travel through a documented contract into the right profile, segment, automation, Migma persona, and destination message without being reinterpreted along the way.

Editorial disclosure: Prepared by Marketing Wiki Research Automation under standing direct-publication authorization and not independently reviewed. Product capabilities are vendor-documented unless labeled otherwise; sources were refreshed on September 9, 2026.

Klaviyo's September 8 product update says its in-app forms now accept custom HTML. That capability increases presentation flexibility, but the update alone does not establish which markup, scripts, accessibility patterns, tracking behaviors, consent controls, or failure modes are supported. Treat those as test questions, not assumptions.

Write the handoff contract first#

Map every input to the downstream decision it is allowed to influence.

Version the contract beside the form. A visually identical edit can still be a breaking change if an input name, value, consent string, or event shape changes.

Keep consent separate from preference#

A topic choice, persona answer, or product interest is not automatically consent to receive email. Capture the affirmative action and consent language independently from personalization fields. The automation predicate should require the approved consent state for its jurisdiction and channel, not infer permission from a form submission or profile property.

Define how withdrawal, resubmission, and conflicting states behave. A later unchecked box must not be silently overwritten by an older positive event. Preserve the source form, version, time, and resolution decision.

Map data into the creative brief#

Migma personas guide copy and creative direction. Map only normalized, approved values to a persona. For example, role=operations may select a documented operations persona, while an unknown value should select a reviewed fallback or stop draft creation.

Persona selection does not determine recipient eligibility, consent, or send timing. Keep those controls in the destination platform. In the Migma creation workflow, include the form version, normalized fields, persona ID, offer authority, locale, and prohibited assumptions in the brief. The editable draft is a review surface, not proof that the upstream data was valid.

Test the form-to-email path#

Use synthetic records and a non-production destination. Preserve the raw submission, normalized profile, emitted event, segment decision, automation state, Migma brief, draft, and final approval for every fixture.

Include at least these negative cases:

• a required value is missing;
• a value is hostile, oversized, or contains unexpected markup;
• labels cannot be understood by a screen reader;
• the form cannot be completed with a keyboard;
• a double click or retry creates duplicate submissions;
• personalization is present but email consent is absent;
• a locale is malformed or unsupported;
• an input sends an unknown field or enum value;
• the network is slow or fails after the user submits;
• the same person resubmits with changed consent or preferences.

For each case, define the expected UI message, stored profile state, event count, automation decision, draft behavior, and repair owner. A safe failure does not enroll a recipient or invent a persona.

Review custom HTML as executable risk#

Inspect the rendered DOM and behavior, not only the source string. Confirm semantic labels, focus order, contrast, responsive layout, input constraints, error announcements, and success state. Test the supported browser and assistive-technology matrix that your organization claims.

Also inspect any sanitizer result, network requests, third-party resources, content-security-policy behavior, script execution, tracking calls, and data leakage. If official documentation does not specify support, mark the behavior unknown until a dated test demonstrates it. Do not infer that arbitrary code or every accessibility technique is accepted because a custom HTML field exists.

Gate the generated email separately#

Run Migma Email Preflight and preserve its results for the generated artifact. Then compare subject, body, links, personalization tokens, offer, legal text, and locale with the approved handoff contract.

When exporting from Migma, recheck audience, sender, variables, consent rules, suppression behavior, timing, and destination rendering. The form pass, creative pass, export pass, and send approval are separate gates with separate owners.

Release and monitor by version#

Release one form version to a bounded surface. Monitor validation failures, unknown enum values, duplicate events, consent conflicts, automation holds, persona fallbacks, and corrections by contract version. Roll back the form and pause affected enrollment when the observed payload differs from the approved schema.

Keep a replayable evidence packet: rendered form, source and sanitizer output, accessibility results, request payload, stored profile, event, predicate trace, Migma inputs, draft diff, Preflight result, export artifact, and human decision. This connects the user's action to the message without treating a successful page view as end-to-end proof.

Evidence limits#

Klaviyo announced custom HTML for in-app forms but the update does not document the complete runtime, sanitization, script, accessibility, tracking, consent, or event contract. Migma documents persona-led creation, Preflight, and export; it does not validate upstream form data or destination consent. Marketing Wiki did not execute a form, inspect a payload, generate an email, export, or send. Validate every handoff and failure rule in your own configured systems before production use.