Core concepts

Five nouns carry the whole platform: organisations, folders, forms, versions and submissions. Everything else — workflows, documents, payments, reports — hangs off those. This page is the map; the other guides are the territory.

The spine: folders → forms → submissions

A folder groups forms. A form collects submissions. That is the entire model, and it is deliberately free of any business vocabulary: an insurer configures a Policies folder and a Claims folder, a support desk configures Tickets, a council configures Permits. None of them waits on a developer, because nothing in Faldaro is specific to a domain — the platform takes the shape of your work.

Folders nest, so the structure can mirror how your organisation is actually arranged rather than a flat list of forms. Open one and its forms are listed with what each has collected — how many submissions, and when the latest arrived — so choosing where to work is a glance, not a tour.

Versions: published means frozen

A form is edited as a draft. Publishing turns that draft into an immutable version and leaves the next edit to a fresh draft. Every submission records which version it was filled against and keeps it forever.

This is what makes editing a live form safe. Change a question, a formula or a workflow and nothing already collected is reinterpreted: old submissions still carry the definition their submitter actually saw. The same rule holds for datasets and document templates.

Immutability protects what exists; it says nothing about whether the next version still behaves. That is what form test cases are for.

Two kinds of data on every submission

A submission carries submitted data — what the person typed — and calculated data — what the server computed. They are stored separately and never merged, which is the mechanism behind a promise made throughout these docs: a browser cannot fabricate a total, because nothing it sends is ever treated as one. Every write re-runs the engine and every read recomputes for display.

Organisations, and the tree they form

Every folder, form and submission belongs to an organisation. Organisations nest into a tree, and a role granted on one organisation also grants its privileges on every organisation beneath it — so administering a parent means administering the whole subtree without a separate assignment per child. Nothing flows upward or sideways.

Isolation between organisations is enforced by the database itself, not by application code: a query that loses its organisation returns nothing rather than everything. Sharing across organisations is possible and deliberately narrow — see sharing with partners.

Privileges, not roles

Permissions are granted as named privileges (form:write, submission:read, billing:read…) collected into roles you assign to people. The privilege list is defined once by the platform and served to every part of the product, so what the interface offers and what the server enforces can never disagree. You cannot grant a privilege you do not hold yourself.

The pieces that hang off a submission

Two ways in, besides the app

A public link lets anyone fill a form with no account at all, and an API key lets another system evaluate and file submissions over the API. Both are bounded by exactly the same privilege checks and isolation as a signed-in person — there is no second, weaker path into your data.