Docs

Forms on Pages

Show a table's Form view on a CMS page and collect answers as records.

Overview

A form section shows one of your organization's tables as a form on a CMS page. Each answer a visitor sends creates a record in that table. The form is the table's saved Form view: its questions, sections, rules, texts, layout and fixed values. The section only chooses which view to show and can override two settings.

Forms on pages use the same system as public form links (/f/<token>): the same snapshot built on the server, the same checks of every answer, the same spam protection and the same audit log. The only difference is where the form lives.

Form sections need the public-forms feature flag (off by default). While it is off, the Sections catalog offers no form, the page editor hides form sections, published pages show nothing where a form was, and every answer is refused.

Related docs:

Create a form section

  1. In the table, switch to Form, set up the questions and save the view. Share the view with the organization: a page belongs to the organization, so private views cannot be used.

  2. Open Content › Sections and choose New form.

  3. Pick the table and one of its shared Form views. You only see tables you can read.

  4. Optionally choose a layout (every question on one page, or one question at a time) and a message after sending, in English and French.

  5. Create the section. It is added to your organization's catalog and appears with a preview of the form.

The section stores only which view to show and the two overrides:

{
  "kind": "form",
  "id": "contact-form",
  "name": "Contact form",
  "version": 1,
  "form": {
    "source": { "kind": "view", "modelSlug": "contacts", "viewId": "<view id>" },
    "layout": "steps",
    "successMessage": { "en": "Thank you!", "fr": "Merci !" }
  }
}

source.kind: "form" is reserved for standalone forms that write to several tables at once. It is accepted in stored sections but refused by validation until it ships.

Place it on a page

In the page editor, insert the form section from the Sections list like any other reusable section. The canvas and draft previews show the form; you can fill it in to try the questions and rules, but a preview never sends an answer: it checks the answers in the browser and shows a notice.

Only organization pages can show forms. Global pages and global sections cannot hold one.

Publish

Publishing the page is what opens the form:

  • The member who publishes needs the page publish rights and dynamic-data:manage on the form's table. Publishing is refused otherwise, and while impersonating another account.

  • At publication, the server reads the saved view and the table's deployed fields and builds the form's snapshot. Nothing sent by the browser or by an assistant is used for it. The snapshot is written in the same transaction as the publication.

  • The publishing member becomes the response owner: records are created with their permissions, checked again for every answer. If they lose access to the table, the form answers "unavailable" until a member with access publishes the page again.

  • Changes to the Form view reach the page the next time the page is published.

Unpublishing or archiving the page, or publishing it without the form, stops the form at once: an answer is accepted only while the page is published at the revision that opened the form.

Answers

Answers go through the page's server action, so forms work on custom domains too, where /api is private. Every answer is checked like a public form link answer: honeypot, rate limits per form and per visitor, size limit, the form's rules (hidden questions are ignored), types and options, then the table's own validation and plan limits. The audit log records public-form.response with the page and section identifiers, never the answers.

The form speaks the page's language: when the Form view has its texts in several languages, a French page shows the French ones, then the form's default language. A consent box must be checked to send, and the server records each consent accepted (its version, the statement as shown, its language and the time) with the record, never in a column. Hidden fields (a campaign parameter of the page address, the page, the referrer, the language, a fixed text) are checked again on the server and kept with the record or written to the field they name; they never grant anything.

Assistants (MCP)

An assistant can create and place a form section in drafts with the usual section tools (yayaw_sections_create_draft, yayaw_sections_save_draft, yayaw_sections_validate) and reference it from a page. The section schema refuses anything but the source and the two overrides. The assistant must be able to read the table. yayaw_table_views_list lists the table's Form views shared with the organization, each with the formSectionSource to use as the section's source, and yayaw_table_view_save prepares or updates such a view (questions, conditions, steps, languages, consents, hidden fields, fixed values) as a draft the team sees; its formPreview lists the consents, hidden fields and languages. Personal views stay out of reach.

Publishing stays a human step: yayaw_pages_publish refuses a page that shows a form, because publishing makes the form accept answers in the publisher's name. yayaw_cms_design_vocabulary_get describes the section under formSection.