FieldScroll has two layers of access control: instance owners, who administer the whole workspace, and organization roles, which grant abilities inside a single organization. A user's permissions are always the combination of these two layers, evaluated per organization.
Instance owners
An instance owner administers your workspace itself: creating and deactivating organizations, managing the full user list, changing workspace settings and branding, and minting instance-scoped API keys. Instance ownership is a flag on the user, separate from any organization role, and it can only be granted or revoked by an existing instance owner.
An instance owner can also enter any organization, not only the ones they are a member of. The organization switcher in the dashboard lists every organization in the workspace, and once the owner switches into one they see and edit its forms and records as if they held the organization admin role there. This is what "administers the whole workspace" has always meant; before, the switcher only offered organizations the owner had been added to, which made the capability hard to reach rather than absent.
Entering an organization the owner is not a member of is written to the audit log as organization.owner_switched, with the organization, the owner, and the time. Switching between organizations the owner actually belongs to is not logged — that is ordinary use, and recording it would bury the entries worth reading. No membership is created by switching, so the organization's own member list does not change.
As the operator running the workspace, you and your team hold instance ownership. Your customers' staff hold organization roles only — they administer their own organization, never your workspace.
Organization roles
Within an organization, access is granted through five roles:
| Role | What it grants |
|---|---|
| Organization admin | Full control of the organization, including granting roles. An organization can have several; the role is granted by an existing org admin or an instance owner. |
| User admin | Manage members and form assignments. |
| Form admin | Create, edit, and publish the organization's forms. |
| Data manager | View and edit all of the organization's records. |
| Data analyst | View all records, read-only. |
Roles are stackable — a user can hold several at once, and their permissions are the union. A team lead might hold user admin and data manager together; a reporting contractor might hold only data analyst. Roles are also per organization: a user who belongs to two organizations can be an organization admin in one and a data analyst in the other, and neither grants anything in the other.
A member with no roles can still fill out and submit forms assigned to them — field crews usually need no role at all.
How permissions are enforced
Role checks happen in the database, alongside the row-level isolation described in multi-tenancy. The same policies that filter rows by organization also check the requesting user's roles before allowing writes — publishing a form requires form admin, and editing all of an organization's records requires data manager (a per-form edit grant can also allow editing one form's records). Checking a record out to a field user — dispatch — follows the same pattern: organization admins always can, and other users need a per-form dispatch grant, set in user management. A record that is checked out is locked against everyone else's edits, whatever their role, until it is resubmitted or the dispatch is revoked. The dashboard currently shows navigation regardless of organization role — only instance-owner screens are hidden — but that is cosmetic either way: the enforcement is in the database, so an action a role does not permit fails no matter how it is requested.
Roles and the API
API keys carry their own permission model — explicit scopes like forms:read or records:write — rather than inheriting a user's roles. The two layers meet at minting: keys are bound to one organization (or to the whole instance, which only instance owners can mint), and a key can never reach past its binding regardless of its scopes. See authentication for the scope list and key types.
Where to manage this
Inviting users, granting and revoking roles, and reviewing each organization's member list all happen in the dashboard — see user management for the workflows.