Flow for WordPress
Forms that can become real workflows
Keep form authoring in WordPress, let the browser handle the live experience, and add durable drafts, review state, discussions, ratings or backend actions only when the process needs them.
From form to process
The page can stay static while the workflow stays live
Flow can submit from the browser to a configured endpoint, so the public WordPress runtime does not have to own form execution.
Progressive architecture
Start with the frontend form experience. Add the Flow Backend in the customer AWS account when the project needs durable drafts, submissions, uploads or workflow actions.
Why Flow
Start with the user journey, then add the runtime it earns
The same form model can cover a simple intake flow or grow into a stateful review process without moving the editing experience out of WordPress.
01
Multi-step journeys
Break long applications, onboarding and intake into understandable stages with conditional paths.
02
Save and resume
Persist draft progress through a compatible backend when users need more than one session to complete the process. See Let Users Save a Long WordPress Form and Continue Later for the dedicated multi-session pattern.
03
Discussion and ratings
Bind live discussion, nested replies and rating inputs to WordPress content when review or participation continues after submission. Use Build a WordPress Review Workflow with Forms, Discussion and Ratings when those signals are part of a structured decision process.
04
Static-friendly runtime
Keep forms and interactive components usable after static publishing by calling the configured runtime directly from the browser. See Add Discussions, Replies and Ratings to a Static WordPress Frontend when participation cannot depend on public PHP.
Capabilities
Move from structured input to structured work
Conditional forms and richer inputs
Use wizard steps, conditional behavior, files, sliders, ratings, tags and other structured fields for more complex intake experiences.
Durable drafts and submissions
With the Flow Backend, save and load drafts, persist final submissions and keep operational state outside the public WordPress request path.
Review, discussion and moderation
Use content-bound discussions, nested replies, identity-aware actions and moderation when a form becomes a collaborative review surface.
Events, webhooks and downstream actions
Continue accepted submissions into email, signed webhooks, EventBridge-oriented routing or other configured workflow actions without blocking the original browser request.
Architecture
Keep form design in WordPress and process state behind an API
The frontend collects and validates user input. A configured endpoint owns persistence and downstream actions, while WordPress remains the authoring and administration layer.
WordPress / static frontend
└─ Flow form / discussion UI
↓ browser runtime
Configured endpoint
├─ custom receiver / webhook
└─ Flow Backend in customer AWS
├─ drafts + submissions
├─ uploads
├─ review / discussion state
└─ workflow events → email / webhooks / actions
The Flow frontend does not require the customer-owned AWS backend for every form. Backend ownership becomes relevant when the project needs durable process state, uploads, workflow execution or independent runtime operations.
Fit
Compare the operating model, not only the field list
The source comparison is intentionally detailed because the main difference is not one isolated feature. Read the rows as a compact operating-model checklist across user journey, state, static delivery and backend expansion.
| Capability | Flow | Contact Form 7 | Gravity Forms |
|---|---|---|---|
| Multi-step form journeys | Built in | No | Yes |
| Save & resume later | Built in | No | Addon / setup dependent |
| Conditional logic for richer UX | Yes | Limited | Yes |
| Static / headless compatibility | Designed for it | Not a natural fit | Not a natural fit |
| Backend-connected workflow path | Core direction | No | Possible, but less native |
| WP Suite / AWS-native platform fit | Yes | No | No |
For a broader operating-model comparison with established WordPress and hosted form platforms, see WP Suite Flow vs Gravity Forms, WPForms, Fluent Forms and Jotform.
Evaluation questions
Choose Flow from the problem you actually have
When is Flow a strong fit for save and resume?
When the form spans multiple sessions and durable draft state must live behind a browser-to-backend boundary. See Let Users Save a Long WordPress Form and Continue Later.
Can Flow replace email and spreadsheet approval chains?
Flow can provide the form and workflow foundation for structured records, review state and downstream actions. See Replace Email and Spreadsheet Approvals with a WordPress Workflow.
Can Flow combine forms, discussion and ratings?
Yes. Flow can pair form input with content-bound discussion and rating data when the review model benefits from them. See Build a WordPress Review Workflow with Forms, Discussion and Ratings.
Can discussions remain live on static WordPress?
Yes when the exported page can reach the configured Flow backend. See Add Discussions, Replies and Ratings to a Static WordPress Frontend for the static participation use case.
Start with the workflow pain
Choose the form problem first, then add only the backend it needs
Use Flow for the frontend journey. Add durable workflow infrastructure when the process requires state, review, discussion or downstream actions beyond a simple submission.