A capable, free, first-party forms plugin that keeps submissions in your own site. Plan for styling, set notifications and webhooks through the API, and look elsewhere for logic or payments.
Pros
- Thirteen field types, file uploads and multi-page forms
- Notifications, digest, autoresponder, webhook and export
- Submissions stay in your own database
- Free, first-party, and works on the Workers free plan
Cons
- Notifications, digest and webhook are not editable in the admin
- Editing a multi-page form in the admin flattens it
- No conditional logic, calculations or payments
- Unstyled output and no invisible Turnstile option
emDash Forms is the first-party forms plugin from the emDash team: contact forms, sign-ups and enquiries, managed in the admin and embedded in any page. We have run version 0.2.10 in production on this site, on emDash 1.3, for the contact, write-for-us and advertising forms. This review covers what it does, what working with it is like day to day, how to get its data into a CRM, and how it compares with the WordPress plugins most migrating teams will be used to.
What it does
It is more capable than a typical contact-form plugin. Forms are built in the admin and dropped into any page as a block, and submissions are stored in the site's own database.
| Area | What emDash Forms offers |
|---|---|
| Field types | Thirteen, from text, email and phone to selects, checkboxes, dates and file uploads up to 10 MB |
| Form structure | Single-page forms in the admin; multi-page forms through the plugin's API |
| After submission | A confirmation message or redirect, email notifications, an optional daily digest and an autoresponder |
| Integration | A webhook per form, and CSV or JSON export of submissions |
| Spam protection | Honeypot or Cloudflare Turnstile, chosen per form |
| Data handling | Submissions marked new, read or archived, starred, and deleted automatically after a retention period you set |
The back-end experience
Day to day, an editor works in two screens.
The forms list shows each form with its slug, status, number of submissions and the date of the last one, with actions to edit, duplicate or delete. The form editor is a straightforward list of fields: add a field, choose its type, label and width, mark it required, set options for selects, and reorder with up and down controls rather than drag and drop. Beside the fields sit the form's settings: the confirmation message or redirect, the submit button label, spam protection and how long submissions are kept.
The submissions screen is a simple inbox. Pick a form, filter by status, and open any submission to see every answer, the submission date and the visitor's country. Each submission can be starred, moved from new to read to archived, or deleted, and the whole set can be exported as CSV or JSON. A Recent Submissions widget also appears on the admin dashboard.
It is clean and quick for what it covers. The gaps are in what the editor does not expose yet:
In practice, a developer or an AI agent sets those values once when the form is created, and editors work in the inbox thereafter. That is how this site runs. It is workable for a small team, and a real limitation for organisations that expect marketers to manage routing and integrations themselves.
What needed work
- It does not match your design out of the box. The plugin's output is plain HTML: labels beside fields, nested borders, help text out of place. Bringing it in line with a design system took a dedicated stylesheet — a day of front-end work, not a reason to avoid it.
- The spam setting needs checking. The plugin can be configured to default new forms to Turnstile, but the admin editor still creates them with the honeypot. Check each form after creating it.
- Turnstile stays visible. The plugin always shows the verification widget. Our newsletter sign-up uses the invisible mode, which only appears when a visitor looks automated; the forms plugin has no option for it yet.
The latest release fixed the three issues we had noted earlier: the daily digest now schedules correctly, a form embedded twice on one page no longer produces duplicate field identifiers, and the plugin's inline error messages now replace the browser's generic validation bubbles.
Getting submissions into a CRM
emDash Forms has no built-in CRM connectors. It has something more general: a webhook. After each submission it sends a JSON message to an address you choose, containing the form's name and identifier, the submission identifier, every answer keyed by field, details of any uploaded files and the time of submission. Four routes follow from that, in order of effort.
| Route | How it works | Best for |
|---|---|---|
| Automation platform | Point the webhook at Zapier, Make or n8n, map the fields once, and create or update the contact in HubSpot, Salesforce, Pipedrive or similar | Most teams; no code, and the platform handles retries and logging |
| CRM's own inbound webhook | Some CRMs and their workflow tools accept a JSON webhook directly; map the payload's fields to contact properties | Teams whose CRM accepts generic JSON |
| A small relay Worker | A Cloudflare Worker receives the webhook, reshapes it, calls the CRM's API and queues retries | High-value leads, custom routing, or strict data rules |
| Scheduled export | Download CSV from the submissions screen and import it into the CRM | Low volume, or as a reconciliation check |
Two properties of the webhook shape how much you should rely on it. It is sent once, without retries, so if the receiving service is down the submission is still safe in emDash but the CRM will not hear about it; a weekly export compared against the CRM closes that gap. And it carries no signature, so the receiving address should be a long, unguessable one (the default for most automation platforms), and the receiver should check the form identifier before acting. As with any form, the privacy page should name the CRM as a recipient.
When you need more than emDash Forms
emDash Forms suits contact forms, enquiries and applications. It has no conditional logic, calculations, payments or quizzes. For those there are three sound paths.
Services such as Typeform, Jotform, Tally or your CRM's own forms embed through emDash's iframe block. Rich logic at once; data is held by the vendor and the styling is theirs.
Collect with emDash Forms and do the routing, scoring and follow-up in an automation platform. Data stays in your site first.
A custom emDash plugin for complex journeys, with your own validation and CRM calls. Higher upfront cost; an AI coding agent shortens it.
If you embed a hosted form, two site settings need attention: a strict content security policy must allow the vendor's address in frames, and the privacy page must name the vendor. Hosted forms also add their own scripts and page weight, so check page speed on the pages that carry them.
Coming from WordPress: WS Form and Fluent Forms
Teams moving from WordPress often use one of the established form builders. Neither runs on emDash — they are WordPress plugins — so the comparison is about what you give up and gain by moving.
| emDash Forms | WS Form | Fluent Forms | |
|---|---|---|---|
| Runs on emDash | Yes, first-party | No, WordPress only | No, WordPress only |
| Price | Free | Free LITE edition; PRO from $59 a year for one site | Free edition; Pro from $79 a year for one site |
| Field types | 13 | 65+ | 65+ |
| Conditional logic | No | Yes | Yes |
| Calculations | No | Yes | Yes |
| Multi-step forms | Through the API | Yes | Yes (Pro) |
| Payments | No | Yes (PayPal and Stripe on higher tiers) | Yes (Stripe, PayPal) |
| CRM connections | Webhook, then your own route | 120+ integrations claimed; HubSpot and Salesforce on the top tier | 60+ integrations in Pro, including HubSpot, Zapier and webhooks |
| Where submissions live | Your emDash database | Your WordPress database | Your WordPress database |
The comparison is not close on features: both WordPress builders are mature products with years of development behind them, and emDash Forms is a young, deliberately simple plugin. What emDash Forms offers in return is first-party support, no licence fee, and submissions that stay in your own site. For a migration, the practical question is which of your existing forms use conditional logic, calculations or payments. Those need one of the alternatives above; the rest move to emDash Forms comfortably.
The recommendation, by where you sit
- Running a WordPress site with complex forms. Inventory them before any move. Forms with logic, payments or deep CRM routing are the hardest part of a form migration, and emDash Forms will not replace them yet.
- Commissioning a new site. Use emDash Forms for contact and enquiry forms, connect it to the CRM through an automation platform, and budget a day to style it. Add a hosted form only where the journey demands it.
- Running an agency. A reusable stylesheet, a standard webhook-to-CRM recipe and a short checklist for each new form turn emDash Forms into a dependable deliverable. The wider build is described in what we learned running emDash in production.
