When a Form Does Not Work Where You Put It

Features that offer you a form — artefacts, AI agents, and the settings on other flows — only list Published forms.

This is confusing because a Draft form is fully functional at its own address, so nothing suggests it is invisible elsewhere.

Open Manage Form Actions and save the screen. Saving it publishes the form. Then reopen the picker.

An embedded form sits in a frame of fixed height, and a form taller than its frame scrolls within it. On a phone this is easy to miss entirely — people do not realise there is more below.

Increase the height generously rather than tightly. If the form is long, consider a shorter version for this placement and ask the rest later.

Skipping the welcome screen in an embed also recovers useful space.

A form's appearance is set on the form, not inherited from the page it sits in. Dropped into your own page or an artefact it can look like a different product, which undermines trust at exactly the wrong moment.

Open Manage Styles and bring the colours, input shapes and heading sizes into line with the surrounding design.

Work through three things.

Is the parameter on the link you actually shared? Somebody arriving at the bare address produces an empty value, which is correct behaviour.

Does the hidden field's parameter name match exactly? It is case-sensitive and must match character for character.

Is the hidden field mapped to a CRM field? An unmapped hidden field captures the value into the completion but it never reaches the contact, so it looks missing when you look at contacts.

Check a completion to tell these apart: if the value is there but not on the contact, it is a mapping problem.

spring-email, Spring Email and spring_email are three different values, so your lists split three ways.

Agree one format and use it everywhere. Lower case with hyphens is a reasonable convention.

Values already collected are not retrospectively normalised, so fix the links and accept some early inconsistency.

Test the printed version from the distance people will actually stand, not the file on screen.

Leave clear space around the code, keep the contrast strong, and avoid printing it over a photograph or a gradient.

If it scans but lands somewhere unexpected, regenerate it — the code encodes the form's address and a campaign value, and an edited or re-saved image may have been corrupted.

Pre-filling reads from the contact record, so only fields mapped to CRM Field can be pre-filled. Anything mapped to Contact Notes or Profile Data, or unmapped, will always arrive empty.

Also confirm the contact identifier in the link is correct and that the contact actually holds the details you expect — a contact with no phone number on file cannot pre-fill a phone field.

After somebody submits a form, their browser remembers them for a year and your forms pre-fill from that record. On a shared or public computer, the next person sees the previous person's details.

The same happens if a pre-filled link is forwarded — it identifies a contact, so whoever opens it sees that contact.

Do not use pre-filled links for anything sent to more than one person, and never post one publicly.

Every surface points at the same live form, so an edit takes effect everywhere at once. Removing or retyping a field can break something that expected it.

There is no list showing where a form is used, so check the features you know about before editing.

For anything substantial, Duplicate the form from the My Forms row menu, change the copy, and test that instead.

Check View Completions. If completions exist, the form is capturing correctly and the problem is downstream — a notification or an action.

If nothing is there, the submission is not completing. The most common cause is a required field hidden by conditional logic, which blocks submission with no visible error.

Walk the form yourself on every path and confirm it can actually be submitted.