Forms
Build forms, collect submissions, and send notifications directly inside EmDash CMS.
Plugin
Forms
Build forms, collect submissions, and send notifications directly inside EmDash CMS.
Product Details
- Category
- Content
- Status
- available
- Version
- Included in beta
- Price
- Included in beta
- License
- MIT
- Release Date
- TBD
- Compatibility
- EmDash CMS beta preview
- Maintainer
- EmDash CMS Team
Links
The Forms plugin is one of the clearest examples of EmDash behaving like a real CMS instead of a static site generator with a thin content layer. It is built for teams that need contact and lead capture, structured submission storage, and notifications—without bolting on a separate form SaaS for every site.
The first-party package lives in the EmDash repository under packages/plugins/forms.
Installation
- Use an EmDash CMS project that matches the compatibility note for this beta (see the main EmDash README for supported versions).
- Add or enable the Forms plugin through the EmDash admin plugin screen, or follow the monorepo instructions in
packages/plugins/formsif you are developing against source. - Deploy or run locally with the same Node and framework versions the core project expects so shared dependencies resolve cleanly.
- After installation, confirm the plugin appears as enabled in admin and that form-related routes or admin sections load without console errors.
If you are evaluating from this marketing site only, use the official demo admin linked from the homepage to explore behavior before you commit it to your own deployment.
Configuration
Exact field names vary by release; treat the plugin source as the source of truth. In general you will configure:
- Notification targets — where submission alerts go (email, internal queues, or downstream hooks provided by your deployment).
- Spam and validation expectations — required fields, max lengths, and any server-side checks the plugin exposes.
- Storage semantics — how long submissions persist and who can read them in admin.
Example (conceptual): a simple contact form might define name, email, and message as required fields, with notifications sent to ops@example.com. Your real configuration will follow the schema and UI shipped with the plugin version you run—verify labels and keys in packages/plugins/forms before production.
Usage scenarios
- Marketing sites — capture demo requests and route them to sales tooling.
- Support portals — structured intake that feeds a ticket system via Webhook Notifier or a custom integration.
- Editorial products — pitch forms, guest post submissions, or corrections workflows that stay inside EmDash instead of leaking PII into random spreadsheets.
Operational tips
- Test submissions in a staging project before pointing DNS at production forms.
- Document retention: submissions may contain personal data, so align with your privacy policy.
- Pair with Audit Log when multiple staff review or export submission data.