Forms & Flows

CoreX Forms & Flows is the administrative path for forms, subscriptions, surveys, and other structured visitor interactions. Open CoreX → Forms & Flows, create a draft, configure every stage, and publish the validated snapshot.

Build and publish

The builder stores stable field identities even when fields move. Configure the field schema, ordered validation, first-match routing and fallback, email bindings, and success behavior before publishing. Every save appends an immutable version; a stale browser receives a conflict instead of overwriting another administrator’s work.

Published flows accept the built-in field types: text, email, phone, number, textarea, select, multi-select, radio, checkbox, date, time, URL, hidden, consent, rating, and step. Extensions can add field types, validation rules, actions, routing targets, email variables, and success states through the Forms registries.

Preview and test

Preview shows the current draft without changing the published visitor version. Run marked test executes the real seven-stage pipeline and stores a submission with the test marker:

validation → protection → storage → routing → email → inbox → timeline

The result panel reports each real stage outcome. Test submissions remain visible for diagnosis but are distinguishable from ordinary submissions and can be excluded from normal metrics and exports.

Add a block

Insert Flow, Form, Success Message, Subscribe, Survey, or CTA + Flow, then choose a published flow in the block sidebar. The Form block defaults to persisted flows and also offers the legacy registered-form source. Dynamic rendering uses the published immutable schema and conditionally loads the shared runtime and token-only RTL-safe styles.

Visitor submissions post to /wp-json/corex/v1/flows/{id}/submit. The browser improves feedback, but the REST boundary re-sanitizes and re-validates every value before the pipeline runs. Inline success messages, page/URL redirects, and registered custom success behavior come from the published version.

Routing and email

Routing rules run by position and stop at the first match; the fallback is mandatory. Supported targets include fixed email, WordPress user, role, team/department, page owner, post author, flow owner, a submitted field value, and registered custom targets.

Email bindings cover submitter confirmation, team notification, and administrator failure alerts. Bind an active Email Studio template and map recipients/reply-to values from the submission. Delivery still follows Email Studio’s environment policy, so Development captures mail and Production requires an explicitly ready provider.

Spam protection (reCAPTCHA v3)

Protection is set per form on the Protection tab: leave it on the site default, or force it on or off for this form. When a reCAPTCHA v3 provider is configured (CoreX → Settings → Captcha) and a form is protected, the provider script loads only on pages that actually contain that form — a page with no protected form makes no request to the provider. Each submission fetches a fresh token at submit time, and the server verifies it against the form’s own expected action, an allowed-hostname list, the token’s age, one-time use, and a score threshold.

The score threshold defaults to 0.3 — conservative for ordinary low-traffic sites. Watch real traffic before raising it; a higher threshold rejects more legitimate visitors. A form may override the global threshold and action on its Protection tab; when it declares neither, its action derives deterministically from the flow slug (corex_form_<slug>) so two forms never share one by accident. The honeypot and rate limiter always run — reCAPTCHA is an added layer, not a replacement — and the secret key never reaches the browser. If a form has no provider configured, it still works; only the honeypot guards it.

With Turnstile or hCaptcha configured, a protected form shows that provider’s widget above its button. The token the widget gives is sent with the form and checked on the server; a submission made before the visitor has passed is held in the browser with a message, and one that reaches the server without a valid token is refused. Neither scores a visitor, so the threshold and the action do not apply to them.

Stored evidence

Each accepted submission records its flow and version, submitted values, hidden and UTM metadata, consent snapshot, spam evidence (including the effective captcha threshold and outcome), resolved route, a typed notification-delivery outcome, Inbox assignment, test marker, and timeline. The delivery outcome is one of accepted, captured, queued, failed, rejected, or not attempted — a submission saved before a mail problem is never relabeled as sent, and a submission saved before delivery tracking existed reads as unavailable, never as success. The submission is always saved before its notification is attempted, so a mail failure can never lose an enquiry.

What CoreX Forms covers

This pipeline covers submissions made through visual flows. A form defined in code has a shorter one: the security token, the rate limit, the trap field, the challenge when the form asks for it, its answers’ rules, and then its own listeners. It stores no spam evidence and no delivery outcome. It does not cover third-party form plugins, custom PHP that bypasses CoreX, direct wp_mail() calls made outside the pipeline, or the WordPress login form. A transport accepting a message is never proof it reached an inbox — see Email Studio.

For code-defined compatibility forms and low-level API details, see Create a form and the frontend runtime.