Forms that react to their own answers.
Conditional logic decides what a field does. Triggers decide what the form does. Both are authored side by side, and both are re-enforced on the server.
Fields on the left, the real form on the right. The preview is the public renderer, logic, triggers and wizard steps included, and it updates as you edit.
One answer. The whole form responds.
A trigger hangs off a field and fires when the answers meet a condition you set.
State reverts. Events fire once.
State actions apply while the condition holds and are undone when it stops. Hide a field because the answer was "no", and changing the answer to "yes" brings it back. You never have to write the inverse rule.
Event actions fire once, on the transition into a branch, and never on the first render. So a toast greets a change of mind instead of ambushing someone who has not typed anything yet.
Because the matching branch and its alternative are separate, an answer swinging back re-fires cleanly.
The trigger: when spend is over £2,000, show a banner while it is true and tell the admins when the form is sent.
What the visitor sees. The banner fills in their name from the form, and the references field slides in, now required.
Some answers mean there is nothing more to ask.
An end-form trigger masks the rest of the form, says why, and turns the button into Finish. You choose whether the answers so far are kept, and the stored entry records how the form ended.
ACME only opens trade accounts for businesses trading six months or more. Pick "Less than 6 months" and the application stops there, politely, with the details kept for later.
Each field knows when it is needed.
Open a field and its logic sits underneath: when it shows (with a fade, slide or scale), when it becomes required, and what counts as a valid answer.
ACME's "Two trade references" is hidden until the spend is over £2,000, required only then, and has to include an email address or phone number. Conditions can test any answer, including ones from an earlier step.
Everything else you would have built by hand.
Show, hide or require a field based on answers already given, including answers from an earlier page of a wizard. Dependent dropdowns and cross-field validation included.
Page breaks and progress. Validation that names what is missing rather than refusing silently. Files and logic survive every step change.
A honeypot pair and configurable rate limiting on every form, with none of it visible to a real visitor.
Forms lay out on a proper responsive grid and collapse correctly on narrow screens. The column control only offers what the renderer can actually produce.
Email on submission, a webhook to anywhere, or a hook your own Tool listens for. Recipients and webhook URLs never reach the browser.
Text, select, checkbox, date and file, plus icon and image pickers, so a form can capture a choice that is visual rather than typed.
What happens on submit: store, email, webhook, a CMS Action, or all four. If one fails the entry is still kept, and the admins are told.
One shortcode, anywhere.
[form name="contact" /]
Drop it in a page, a card, a slideover or a tab. The submit route resolves the form's actions server side, so the page never carries them.
Everything lands in the admin.
Submissions are stored, searchable and exportable as CSV or JSON, with filters for new entries and spam. They live in a collection, so they can also be shown on a page like any other.
Each application is named after the sender. Filter, search and pick a date range, open one to read it all, or right-click to copy, email the sender or mark it as spam.