Storefront integration
How a configured form makes it to the visible part of your shop depends on the form type.
Placement options
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:
Open Content → Shopping Experiences
Start the layout editor and pick a section
Drag the Form block
In the right element settings select your form
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-invalidmarkers identical to Shopware defaults (e.g. account login)Server-side — robust and unable to bypass; uses the Shopware standard
DataValidatorwith 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?
