Forms and transactional email

Two halves of the same conversation. Forms are how a buyer asks you something the shop cannot answer on its own. Transactional messages are how the platform answers: order confirmations, quote notifications, password resets.

Forms

Go to Experience Studio › Forms. It has two tabs: Forms, where you build them, and Form Requests, where the submissions land.

Build one

1. Select New form.
2. In Settings, set the Name, the Slug (URL-safe and unique), the default language, the submit button label and the success message.
3. In Builder, drag elements from the palette: inputs (text, textarea, email, phone, number, date), choices (select, radio, checkbox), content (heading, paragraph, image) and a product reference.
4. Select a field to configure it: Label, Field name (the key the value is stored under in the submission, so treat it as permanent), placeholder, help text, and whether it is required.
5. Add validation where it earns its place: email address, URL, numbers only, a length range like 3,64, a numeric range like 1,100, or a regular expression for a format you actually control.
6. Use conditional display to show a field only when another one has a given value. This is how one form serves three cases without becoming three forms.
7. Save, and set the status to Live. Longer forms can be split into steps, with a thank-you page shown after submission.

Field labels are translated per language; the default language holds the base labels and an empty translation falls back to it, so a partly translated form still works rather than showing blanks.

The product field

The product element is the B2B-specific one. It is pre-filled from a query parameter in the page URL or from the context the storefront passes in, so a "request a price" link on a product page arrives at the form already knowing which article the buyer is asking about.

Use it for price requests, availability enquiries, quotes and spare-part identification. It pairs directly with a price entry of type on request: the catalog says "ask us", the form already knows what about. A form that makes the buyer retype 4711-A is a form that gets abandoned.

Route the submission

Every submission is stored under Form Requests with a status of new, read, archived or spam. That list is a fallback. Nobody watches it, so do not treat it as the process.

Two mechanisms turn a submission into work somebody does:

• An event fires on every submission. Automations filter it by the form's slug, which is how a submission becomes an email to sales, a CRM record, or a workflow. Build that in the Integration Studio; see Build a workflow.
• After-submit actions can be chained on the form itself: write the data into an app's entity with a field mapping, emit a named event such as contact.requested, or call a webhook.

There is also a notify email for the simple case: one address that gets told a submission arrived.

Transactional messages

Go to Experience Studio › Messaging. It covers templates, the events that trigger them, and every message that went out — over email, SMS, WhatsApp and push.

A template that names no layout is framed by the default one. Deleting a layout moves its templates to the default and rebuilds their mail on that frame.

Edit a template

Templates are built from blocks (hero, headline, text, image, button, list, table, divider, spacer) inside one-, two- or three-column containers. The header and footer come from the layout and are not edited here. A section you reuse can be saved as a module; an inserted module is an independent copy, so editing the module later does not change templates already using it.

Email is not a web page, and the editor is honest about it: a carousel only swipes in a handful of mail clients, mail clients do not play video, and a Raw HTML block is passed through untouched — templates containing one are flagged Rendering not guaranteed.

Providers and suppressions

Bring your own provider account or stay on the platform's. Credentials are stored encrypted and never shown again: to change one you replace it. A check reaches the provider with what is stored and sends nothing. Providers can differ per market.

An address on the suppression list is not mailed, and there are two kinds: blocks everything means the address itself is the problem, a hard bounce or a spam complaint, so nothing goes there, transactional mail included. Marketing only means somebody left a newsletter; a password reset still reaches them.

What to check

• Submit every live form once from the real storefront and confirm both the submission and its routing: the mail arrived, the workflow ran.
• Open each form in every language you published, and on a phone.
• Run the provider check in Messaging.
• Place a test order and confirm the confirmation arrives, in the right language, from the right sender.
• Watch the Messaging overview: a rising failure count is the earliest warning that order confirmations are not arriving.

When it does not work

• The storefront shows no form: the slug does not match, or the form is still draft rather than live.
• The product field is empty: the link is not passing the parameter the field expects. Check the field name against the link.
• Submissions arrive but nothing happens: the after-submit action is disabled, or the automation filters on a different slug.
• One customer gets no mail: check the suppression list first. A hard bounce two months ago is still blocking today.
• Mail lands in spam: the cause is in the sending domain's authorisation records, and hardly ever in the template.

Next

• Events and webhooks: what a submission can trigger.
• Pre-launch checks: the full list before go-live.