Skip to content

Forms

Add a form element, define its fields, and publish — MATRIZ handles the rest:

  • Submissions land in your CMS submissions inbox, ready for the same filtering and workflow as any other content.
  • Spam protection is built in: honeypot fields, rate limiting, and human-verification challenges — no configuration needed.
  • Configure what happens after submit: show a message or redirect to a thank-you page.
  • Trigger email notifications and automation flows from new submissions.

Forms work on published pages even with JavaScript disabled — they degrade to a standard browser submit with a redirect.

Field routing is enforced server-side: a visitor cannot invent fields or write into columns your form does not declare.

Every form has a settings panel (select the form on the canvas, then look at its Properties panel) covering:

  • Success — a message to show, or a page to redirect to, after a submission.
  • Spam — the honeypot and rate-limiting protections are always on; no configuration needed here.
  • Identity — whether a member may submit more than once. Leave it open for an unlimited inbox, or restrict it to one entry per member, or one entry per member per edition (or any other field you choose as the scope). With a scope set, submitting again replaces that member’s existing entry for that scope instead of creating a duplicate — the same submission, updated in place.
  • Gates — when the form accepts submissions: always open, an explicit date window (opens/closes, with a message to show once closed), or “the current period of <schedule>’s submit switch” when the form is wired to an edition (see Recurring editions).
  • Derive — fields that are filled in automatically at submission time rather than by the visitor: a timestamp, the current edition, the current period and its price. A derived field always overwrites whatever value a visitor’s browser sent for that key — a visitor cannot back-date a submission or set their own price by tampering with the form.

A form can collect one or more files or images. Uploads always require the visitor to be signed in as a member first — MATRIZ has no anonymous upload path. An image field can be configured to accept multiple images: the visitor picks or drops several at once, uploads happen one at a time with progress, and the visitor can reorder or remove any of them before submitting. Re-submitting a multi-image field replaces the whole set, not just the newly added ones.

A form on a detail page (or inside a list card) can email the person the page’s CMS item belongs to — an artist on their own page, a seller on a listing — instead of you. Turn on Item owner in the form’s settings and pick:

  • Collection — the collection the page (or card) is bound to; pre-filled from the page’s detail collection.
  • Email field — where the owner’s address lives: a field on the item (text_email) or, one reference away, on a linked entry (ref_user.text_email).
  • Consent (optional, recommended) — a yes/no field the owner controls (ref_user.boolean_email_publico). When it is off or empty, the submission is still saved to your inbox but nothing is sent, and the visitor sees your “if refused” message.
  • Subject, copy to (up to five of your own addresses), and a per-item hourly limit (default 5).

The owner’s address is looked up on the server from the item the form is on: the published form carries only a reference to that item, visitors never see or choose the address, and a reference to any other item is refused. The owner can reply straight to the visitor (their address is the Reply-To). Merge fields {{item_title}} and your form’s own fields work in the subject and in a designer template.

To also show a “reveal email” link, you don’t need this feature: bind a link’s URL to the email field (a mailto:{{value}} template; the binding can reach one reference away) and give the link a visibility condition on the consent field, so it only renders for owners who agreed. One limit today: a visibility condition reads the page’s own item only — it cannot follow a reference — so the consent flag must live on the item the page is bound to (e.g. a person’s own page). On a page bound to a linked entry (an artwork folder whose owner is ref_user), the link’s URL can still follow the reference, but hiding the link for owners who did not consent can’t be expressed yet; the contact form above is unaffected (its consent check runs on the server and does follow the reference).