Features

A form builder that can hold a real process

Most form tools stop at fields and a submit button. Formora adds the parts a working data-collection process actually needs: rules that compute and validate across questions, reference data managed in one place, versioned publishing, and a way to follow the same subject across many forms over time.

In depth

The four capabilities worth choosing it for

Each of these has a documentation section of its own. These are the summaries.

Rules and logic

Questions that compute, require and validate each other

Conditional logic shows and hides questions. Rules go further: they derive values, make a field required only in the situations where it matters, and enforce constraints that span several answers at once. Rules are written against stable question keys, so renaming a label never breaks a formula.

Read the docs →
Calculated fields
A question whose value is derived — an age from a date of birth, a total from line items. The respondent sees it fill in as they answer, read-only rather than as an empty box.
Conditional requiredness
"Required only when the answer to something else was X", without turning one question into three near-duplicates.
Cross-question validation
An end date before its start date, a total that must match its parts. The message appears against the field it concerns.
Re-run on the server
The browser evaluates rules for immediate feedback; the API evaluates the identical compiled plan again and its result is what gets stored. Client-supplied values for calculated fields are discarded.

Option lists

Reference data managed once, used everywhere

A list of 784 districts does not belong pasted into a dropdown on four different forms. Option lists hold that data centrally, upload from CSV, and bind to any choice question — so correcting a spelling fixes it everywhere at once.

Read the docs →
Cascading dropdowns
District narrows Block, Block narrows School. Each level offers only the options belonging to the answer above it.
Lookups and auto-fill
Attach metadata to a list item and pull it into other fields when that item is chosen — a code, a region, a contact.
Searchable at any size
Large lists become type-to-search automatically rather than a select someone has to scroll for a minute.
Organization or platform scope
Keep a list to one workspace, or publish a shared dictionary that every workspace can draw on.

Publishing

Published versions are immutable, and responses remember theirs

Publishing freezes a version of the form. Editing afterwards changes the draft, not what respondents are currently filling in, until you publish again. Every response records the version it was submitted against, so an answer is always readable against the questions that were actually asked.

Read the docs →
Draft and live are separate
The builder shows unpublished changes explicitly, so nobody discovers a half-finished edit went live an hour ago.
Responses bind to a version
Reworded a question last month? Older responses still display against the wording their respondent saw.
Access controls on the link
Password protection, sign-in requirement, an expiry date, a response cap that closes the form on its own, and one-response-per-person.

Data apps

Many forms about the same subject, over time

A monitoring visit is not one form. It is a respondent block, then a section repeated per school visited, then a summary — and next quarter the same subject is visited again. A data app is one link that walks a field worker through that whole sequence and files the result under the subject it concerns.

Read the docs →
Record types
Define the subject an app collects data about — a school, a household, a patient — and what identifies it.
Ordered, repeatable, conditional steps
Each step is a form, filled once or any number of times, with minimums and maximums, and skipped entirely when it does not apply.
Records and timeline
Everything ever collected about one subject, in one place, in the order it happened.

Security

What we do, stated plainly

These are engineering measures that are implemented, not certifications. See security and compliance for what we do and do not hold.

Two-factor authentication

TOTP from any authenticator app, with single-use recovery codes. Secrets are encrypted at rest, and turning it off requires the account password.

Server-side answer validation

Every submission is re-validated against the published version: required fields, types, option membership, bounds, and payload size. The browser’s word is never taken for it.

Guarded outbound webhooks

HTTPS only, with addresses resolved and checked at delivery time so a webhook cannot be pointed at an internal or cloud-metadata address.

Sessions
One day, fixed at sign-in. Nothing extends it in the background; when it ends you are signed out.
Rate limiting
Shared across servers, with stricter limits on sign-in, two-factor and password reset.
File uploads
Type and extension allowlisted, size enforced at the storage layer, and checked against the actual stored object.
Tenant isolation
Every request is scoped to one organization and checked server-side, including files and option lists.
Secrets at rest
Webhook secrets and two-factor seeds are encrypted; the API never returns them once set.
Response data
Yours. Exportable at any time, and deletable — including individual responses.

Reference

Every field type

What each one stores and when to reach for it is covered in the field types documentation.

  • Short text
  • Long text
  • Number
  • Email
  • Phone
  • URL
  • Single choice
  • Multiple choice
  • Dropdown
  • Star rating
  • NPS
  • Slider
  • Date
  • File upload
  • Signature
  • Matrix
  • Section header
  • Repeating section

Build your first form

Create a workspace, build a form, and share a link. Nothing to install, and no card needed to start.