Build a small contact form on your own oCMS installation, then follow a submission from the public page into the administration interface. This example uses three fields: name, email address and message.

Practice in a separate local installation first. Use an administrator account for form configuration. The shared demo is useful for exploring the interface, but disables editing and CSV export. Follow configuration and deployment when preparing your own public site.

1. Decide what to collect

Collect what you need to answer an enquiry. For this exercise, use these labels and stable internal field names:

Name · name
Text field, required. Allow 2–80 characters.
Email address · email
Email field, required. The field type checks the address format.
Message · message
Textarea, required. Allow 10–2,000 characters.

Add a short description explaining who receives the enquiry and link to your own site's privacy information. Decide who may review submissions and how long to retain them before opening the form to visitors.

2. Create the form and its fields

In Admin → Forms, create a form named Workshop contact, with slug workshop-contact, the appropriate content language, a public title and a short description. Use an unused slug, or edit the existing form when it is the one you intend to maintain.

Add the three fields above, set their types and required state, then arrange them in name → email → message order. Use visible labels; placeholders can provide an example without replacing the label.

For the message field's validation settings, use:

{"minLength": 10, "maxLength": 2000}

Use the corresponding 2 and 80 limits for the name. Save the form and fields, and choose an honest success message such as Your message has been saved. Thank you. This confirms storage without promising an email delivery or response time.

3. Check validation and the saved result

An active default-language form uses /forms/workshop-contact. Other active languages use their language prefix, such as /ru/forms/workshop-contact. Check the actual URL for the form you created.

  1. Open the form while signed out. Check the title, instructions, labels, required indicators and keyboard order on desktop and mobile.
  2. Try submitting empty required fields, an invalid email address and a message shorter than ten characters. Correct the reported error and check that useful entered values remain available. Browser validation may catch an error before it reaches the server.
  3. Submit a harmless example: Alex Example, alex@example.com, and I would like to discuss a small website. Confirm the configured success message.
  4. Open this form's Submissions list in Admin and find the new record. Check that its values match what you entered. The saved record is a better check than the success message alone.

A local form check does not exercise an external captcha service. Complete the production protection check below before linking to your public form.

4. Configure and test hCaptcha

In Admin → hCaptcha, enable protection and configure valid site and secret keys for the public domain. Keep the secret key private. Add one captcha field to the form and save it.

Production requires form captcha by default. An active form without the required field or verifier can return HTTP 503 instead of accepting a submission. Keep that safeguard enabled and correct the configuration. The hCaptcha reference covers the module settings.

At the real public address, check that the widget loads, an incomplete challenge prevents acceptance, and a completed challenge allows a new harmless submission to reach Admin. Check the actual submission, rather than treating saved keys as a verifier test. The built-in honeypot supplements captcha; keep it out of the keyboard sequence in a custom theme.

5. Review and export submissions

Use Admin → Forms → Workshop contact → Submissions to review records. Opening a submission marks it read. Check the field values, submission time and relevant request context when investigating a problem.

Use the form's CSV export action when you need an offline copy. The export contains all submissions for that form, with record information and field columns. Verify its row count and a known example before using the file. Restrict access to exports and remove copies when they are no longer needed; they can contain personal details and IP addresses.

For notifications or integrations, see the existing webhook reference and its form.submitted event. Configure and test that delivery separately from the saved submission, and review the payload's data mode before sending personal information to another service.

6. Link the form and maintain it

When protection and the full submission path work, add a clearly labelled link to the form in your site's menu or contact page. A translated form needs its own labels, instructions and success message; check its language-prefixed URL too.

After a theme or configuration change, repeat keyboard navigation, validation, captcha and successful-submission checks. Review stored submissions on your chosen schedule and remove data according to your site's policy. Deactivate a form that is no longer used instead of leaving its public endpoint unattended.

For a failure, record the HTTP status, relevant redacted log message and reproduction steps using Support. The complete Forms reference lists field types, translations, submission management and export behaviour.

Source: https://ocms.tech/forms-guide