For the complete documentation index, see llms.txt. This page is also available as Markdown.

Storefront integration

How a configured form makes it to the visible part of your shop depends on the form type.

Placement options

Option
When to use

CMS element "Form"

free placement inside a Shopping Experience

Special form "Product inquiry"

modal trigger on every PDP, no CMS layout needed

Direct Twig include

for theme developers

CMS element "Form"

The Form Toolkit ships its own CMS block and CMS element. Both work in every Shopping Experience:

  1. Open Content → Shopping Experiences

  2. Start the layout editor and pick a section

  3. Drag the Form block

  4. In the right element settings select your form

  5. Save the layout

The element renders cleanly in your shop's theme — including buttons, input styling, the Bootstrap grid and the validation layout.

More in CMS elements.

Special form "Product inquiry" (Premium)

With the Product inquiry form type the product detail page automatically shows an "Ask about this product" trigger. A click opens a full-screen modal with your form.

  • You do not need to place the inquiry in any CMS layout — it hooks into the buy widget automatically.

  • In the Special form tab you define visibility conditions — on which products, customer groups, sales channels or dynamic product groups the inquiry should appear.

  • Hidden inputs in the background ship product ID, product number, product name, price and URL with the submission — so you instantly know which product the inquiry was about.

Multi-step forms (wizard)

As soon as your form contains two or more Wizard step elements it is rendered as a multi-step form: with a stepper, progress bar, "Previous / Next" buttons and a final confirmation step.

Conditional fields

Fields or groups with visibility conditions are shown or hidden whenever a referenced value changes. Hidden inputs are disabled — the server skips validation and storage for them.

Validation

Forms use two validation layers:

  • Client-side — instant hint below the field once the customer clicks submit; is-invalid markers identical to Shopware defaults (e.g. account login)

  • Server-side — robust and unable to bypass; uses the Shopware standard DataValidator with Symfony constraints

Each field type triggers the matching rules (required, valid email, numeric range, allowed choices, file size & extension).

Response behaviour

What happens after a successful submission depends on the response type:

  • Success notice — a Bootstrap alert replaces the fields. You can override the text per language.

  • Redirect to URL (Premium) — the browser navigates to the target URL after an optional delay (ms).

Multi-language

Forms, fields, labels, placeholders, choices, mail templates and success messages — everything is translatable per language. Sales channel language switches work out of the box.

Headless integration

Every storefront route is also available as a Store API endpoint. Custom front-ends submit via /store-api/prems/form/submit. See Store API for the full reference.

Last updated

Was this helpful?