A FieldScroll workspace is built from a small number of entities. Understanding how they relate explains most of the platform's behavior — who sees what, why editing a form never breaks data collection in the field, and how a record stays tied to the exact form it was captured against.
The entities
| Entity | What it is |
|---|---|
| Workspace | Your whole deployment: branding, settings, and everything below. You run one. |
| Organization | A container for one of your customers. Holds members, forms, and records, isolated from every other organization. |
| User | A person who signs in. Users belong to organizations through memberships, and one user can belong to several organizations with different roles in each. |
| Form (draft) | The editable definition of what to collect — fields, validation, visibility rules. Only visible in the dashboard. |
| Published version | An immutable snapshot of a form, created each time you publish. This is what mobile devices download and capture against. |
| Record | One completed submission of a published version, with the entered values plus capture metadata (who, when, where, which device). |
Workspace → organizations → everything else
The hierarchy is strict: a workspace contains organizations, and every form and record belongs to exactly one organization. Users are the one entity that can span organizations — a consultant can be a member of two of your customers' organizations, with a different role in each. What that membership permits is covered in roles and permissions, and how the boundary is enforced is covered in multi-tenancy.
Drafts and published versions
Forms exist in two states, stored separately.
The draft is what you edit in the form builder. You can change it freely — add fields, reorder sections, adjust validation — and nothing in the field is affected, because devices never see drafts.
Publishing takes a snapshot of the draft and saves it as a numbered version: version 1, version 2, and so on. Each version is immutable — it cannot be modified after it is created, only superseded by the next publish. The version carries a changelog, who published it (when a person did — API-published versions carry no user), and when. Mobile devices download only the current published version of each form their user is assigned to collect with.
This split is why mid-cycle edits are safe. A crew can keep collecting against version 3 all week while you rework the draft, and nothing changes on their devices until you publish version 4.
Records reference the version they were captured against
Every record stores a reference to the specific published version — not just the form, but the version number. A record captured against version 2 stays interpretable against version 2's field definitions forever, even after you publish version 5 with different fields. There is no migration step and no risk of old data being reread against a newer, mismatched structure.
The stored record never changes, but its presentation can: when a newer version is compatible with the one a record was captured against, the dashboard and the mobile app show that record together with newer ones, as one dataset. When the change is breaking, older records stay visibly on their own versions. How that comparison works — and when a record adopts a newer version — is covered in form versions.
Records also carry submission metadata: the submitting user, the submission timestamp, device details, and GPS coordinates when the form captures them. The security page covers how this metadata serves as an audit trail.
For the screens where you work with these entities, see forms and records.