JetFormBuilder takes a different route to the same destination. Rather than shipping its own form canvas, it builds forms out of native blocks in the WordPress editor, so a form is composed with the same interface as a page and styled with the same block controls. For anyone already committed to the block editor, that removes an entire layer of tooling.
The interesting part is not the builder. It is the list of post-submit actions, because JetFormBuilder treats what happens after a submission as a first-class configuration rather than an afterthought. That makes it stronger than most plugins on one axis and leaves a specific gap on another, and both are worth naming precisely.
Building with blocks instead of a form canvas
The design decision is worth understanding first, because it changes what the plugin is good at. Fields are blocks. There are 24 or more of them, and they are assembled in the same editor as the rest of the site, mixed and arranged into rows and columns using the ordinary block layout tools rather than a separate grid inside a form builder.
Styling runs through JetStyleManager, which exposes fonts and style settings for each field along with the text box, the form description, the required mark and the content label. A multi-step form is built with a Form Page Break block that splits fields into separate tabs, with a customisable button to advance and a Form Progress bar to show first, current and last step. Form Patterns ship pre-built layouts for contact, login and register, application, profile, booking and subscription forms.
Two consequences follow. The first is that anyone comfortable with the block editor has nothing new to learn, and inline editing of labels and descriptions happens exactly where it does everywhere else. The second is that the form is tied to the block editor's conventions rather than the plugin's own, which is a benefit on a block-built site and an obstacle elsewhere. Crocoblock's own documentation notes that Bricks is only partially supported, with six JetPlugins integrated including JetFormBuilder, so the fit is best on Gutenberg and Elementor and thinner on other builders.
There is also a migration path worth knowing about: forms created through JetEngine can be duplicated into Gutenberg in one click, which matters for the large number of sites that started with JetEngine forms before this plugin existed.
Post-submit actions are the real feature
The plugin's own description puts twelve actions on the list, to be run in whatever combination a form needs after submission on the front end: Send Email, Insert or Update Post, Register User, Update User, Update Options, Call Hook, Call Webhook, Redirect to Page, MailChimp, ActiveCampaign, GetResponse, and Save Form Record.
Read that list carefully, because it is not the same as a notification settings panel. Insert or Update Post means a submission can create content. Register User and Update User mean a form can be an account signup or a profile edit. Update Options means a form can write to site settings. Call Hook drops the submission into PHP, and Call Webhook sends it anywhere else.
That is a form plugin designed to change the state of the site, not just to send you a message about it. For a directory, a membership area, a listings site or anything where the submission is supposed to become a record that other pages display, this is the right shape and a considerable saving over wiring the same thing together by hand.
Conditional logic applies in two places, which is less common than it sounds. Field visibility works the way most builders do it. Separately, the conditions can be set on the post-submit actions themselves, so an action runs or does not run depending on what was submitted. A form can create a post for one category of submission and only send an email for another, without duplicating the form.
Save Form Record, and what the records screen holds
Save Form Record is the action that stores the submission, and it is worth being clear that it is an action rather than a default. A form without it processes the submission and keeps nothing. That is deliberate, and it is useful for a form that genuinely should not retain personal data, but it is also the reason some sites discover after a month that nothing was ever stored.
With it enabled, records land in a dashboard screen where the plugin's description says you can check their status, basic data, and the data filled into each field, and review error details where something failed. Version 3.5.0 added visibility controls for Form Records that restrict access for unprivileged users, which is a real improvement: before that, deciding who could read submitted data was harder than it should have been.
Payments get their own view. WooCommerce, Stripe and PayPal are supported for one-off, recurring, fixed, variable and user-entered amounts, and the dashboard shows payment status, date and amount in one place. For an order or donation form, that is most of what is needed.
The plugin sits at 80,000 or more active installations on the WordPress plugin directory, requires WordPress 6.1 or higher and PHP 7.0 or higher, and is published by Crocoblock. Development happens in public on GitHub, which is where the vendor directs bug reports, and the changelog cites individual issue numbers against fixes. For anyone who has waited on a support ticket to find out whether a bug was even acknowledged, that visibility is worth something.
What the records screen does not carry
Everything above treats a submission as data to be processed. The operational question treats it as a piece of work waiting for a person, and that is where the screen stops helping.
There is no owner on a record. Nothing says which member of staff took responsibility for a submission, so on a team of three that fact lives in a chat message or in nobody's head. The status field exists, but it is the processing status: whether the actions ran, and whether any of them errored. That is a technical outcome, not a position in a pipeline. A record marked successful means the email was sent and the post was created. It says nothing about whether a human has read the thing, decided anything, or replied.
The reply is the sharper gap. Send Email covers the templated message well, and conditional actions mean different submissions can trigger different templates. A message written individually to one applicant about one detail is composed in a mail client. Once it goes out from there, the only copy is in one person's sent folder, and the record in WordPress has no idea the exchange happened.
This is not a criticism of the plugin. A form builder whose job is to turn submissions into site state has done that job, and done it unusually well. It is a boundary. The friction people attribute to the plugin is usually the work sitting on the far side of it.
Where the automation route runs out
The natural instinct is to automate past the gap. Call Webhook reaches n8n, Zapier or Make, and from there a submission can create a card on a board, a row in a table, or a ticket somewhere else. For a lot of processes that is a complete answer and the right one.
It runs out in a specific place: the human reply. An automation can create a task saying somebody should answer this person. It cannot write the answer, and it cannot bring the sent message back to sit next to the submission. So the record of the decision lives in one system, the record of the conversation lives in a mailbox, and reconciling them is manual work that grows with volume. Worth checking against the use cases that match your intake before adding a fourth tool to the chain.
What the PRO bundle costs
JetFormBuilder's free build is genuinely capable, with 24 or more field blocks, repeaters, calculated fields, multi-step forms with a progress bar, input masks, conditional logic and the full post-submit action list. The PRO add-ons cover advanced integrations, autocomplete and extended payment handling.
Pricing is a bundle rather than a single-plugin licence. Crocoblock sells plans that carry JetFormBuilder and its PRO add-ons alongside the rest of the JetPlugins suite.
| Plan | Sites | Price | Updates and support |
|---|---|---|---|
| All-Inclusive | 1 | $199 per year | 1 year |
| All-Inclusive Plus | 1 | $249 per year | 1 year |
| Lifetime | Unlimited | $999 once | Forever |
There are also builder-specific bundles at $199 per year for one site, which include JetFormBuilder and its PRO add-ons with a subset of the suite. Crocoblock states a 30-day money-back guarantee and no free trial.
The axis is what matters. The bill grows with the number of websites, and never with the number of people reading submissions. A single site with a team of twelve pays the same as a single site with one administrator. For an in-house team on one property, that is favourable. For an agency carrying many client sites, the Lifetime tier exists precisely because the per-site model gets expensive otherwise.
| Priced by | Cheap when | Expensive when |
|---|---|---|
| Sites | Many people, one site | Many client sites, one coordinator |
| Submission volume | Low steady intake | A seasonal spike |
| Seats | One or two handlers | Everyone needs access |
Self-hosting is the trade, in both directions
Because records are rows in your own database and uploads are files on your own server, submitted data never leaves infrastructure you control. For intake that includes identity documents, health information or anything with a residency requirement, that single fact often decides the question, and no hosted service can match it.
The cost is standing maintenance. The changelog shows the shape of it: honeypot protection not preventing submission when the honeypot field was not empty, accessibility fixes, server-side validation added in 3.5.0, a fatal error on update when a user role was empty. Those are ordinary entries for an actively developed plugin, and the vendor fixing them in public is the behaviour you want. The consequence is that somebody has to apply each release, on every site, reasonably promptly, on software that handles uploads and payment fields.
Add mail delivery to the same list. Send Email leaving a WordPress server without an authenticated sending path lands in spam often enough to matter, and a missing acknowledgement looks, from the respondent's side, exactly like a form that failed. That is worth fixing before anything else, because it is cheap and the failure is silent.
What to change first
Confirm Save Form Record is actually on the forms you care about, then count last month's submissions against the number of replies a person typed by hand. If the second number is a large fraction of the first, the plugin is doing its job and the handling is the bottleneck, and no additional post-submit action closes that. Keep the owner, the status and the reply on the response itself, and weigh options by how they price access against the number of people who genuinely need it, which is the axis Halict is built around.
Q1. Does JetFormBuilder save submissions by default?
No. Storing a submission is a post-submit action called Save Form Record, and a form without it processes the submission and keeps nothing. That is useful for forms that should not retain personal data, but it is also why some sites find out weeks later that no records exist.
Q2. How much does JetFormBuilder PRO cost?
It is sold inside Crocoblock bundles rather than as a standalone plugin licence. All-Inclusive is $199 per year for one site, All-Inclusive Plus is $249 per year for one site, and Lifetime is $999 once for unlimited sites with permanent updates. Builder-specific bundles including JetFormBuilder and its PRO add-ons are also $199 per year for one site. A 30-day money-back guarantee applies and there is no free trial.
Q3. What can JetFormBuilder do after a submission besides sending an email?
The action list includes Insert or Update Post, Register User, Update User, Update Options, Call Hook, Call Webhook, Redirect to Page, MailChimp, ActiveCampaign, GetResponse and Save Form Record. Conditions can be set on the actions themselves, so one form can create a post for some submissions and only send an email for others.
Q4. Can a team share the work of handling form records?
Not from the records screen. There is no owner field, and the status shown is the processing status of the actions rather than a position in a pipeline, so a record marked successful only means the actions ran. Version 3.5.0 added visibility controls that restrict record access for unprivileged users, which controls who can read data but does not assign it.
Q5. Does JetFormBuilder keep a record of replies sent to a respondent?
Automated messages sent through the Send Email action are part of the record. A reply typed individually in a mail client is not, so the only copy lives in one person's sent folder while the record in WordPress shows nothing about it.