Roles and permissions
Two levels of access: your workspace role decides what you administer, your project role decides what you see inside each project.
Workspace roles
A workspace is the container for everything: members, projects, forms and the data they collect. Three roles exist at this level, plus the owner.
| Role | What it can do |
|---|---|
| Owner | The single account the workspace belongs to. Everything an admin can do, plus the two owner-only settings — anonymous collection and privileged role assignment — and ownership transfer. |
| Admin | Manages members, invitations, workspace settings and documents, and creates and manages projects. In every project of the workspace, an admin keeps full access to the data. |
| Manager | The same day-to-day powers as an admin: members, invitations, settings, projects and data. The billing surface stays with the owner and admins. |
| Member | Sees the workspace member list and the list of projects. Inside a project, their project role decides what they can see and do. |
Project roles
Each project keeps its own member list, and each membership carries one role.
| Role | What it can do |
|---|---|
| Analyst | Full access to the project: forms, datasets, submissions, dashboards and reports, with the ability to edit and validate data. Does not manage the member list. |
| Validator | Reviews submissions: reads the project's forms, datasets and dashboards, and validates entries in the review queue. |
| Surveyor | Collects data: creates submissions and reads the forms and datasets needed for collection. In the review queue, only their own submissions appear. |
| Guest | Read-only access: views the project's forms, datasets, submissions and dashboards, and changes nothing. |
Members and invitations
Invite people by email and give them a workspace role. Invitations expire after the workspace invitation expiry — 7 days by default.
- A pending invitation can be resent; a revoked one can be restored; the list keeps the full history (invited, accepted, rejected, revoked, expired).
- Removing a member ends their access but keeps the record: the member can be restored later, and their project assignments are reapplied.
- Submissions already collected stay in the project.
Regions
A project membership can carry assigned countries and regions, and the assignment decides which submissions the member sees.
- One or more regions assigned: the member only sees submissions from those regions.
- No region assigned: the member is not restricted by region — only the project perimeter applies.
- Project creators, the workspace owner and workspace admins and managers always see the whole project, whatever the assignment.
The workspace setting Region fail-closed (on by default) keeps this boundary active; with the setting off, region filtering no longer applies.
Managed surveyors
Field teams do not always have email addresses. The owner, an admin or a manager can create a managed account for a surveyor from the member list: first name, last name, username and password.
Managed accounts have no email address. They sign in to the mobile collection app (KoboCollect or ODK Collect) with their username and password — the API accepts either a username or an email as the credential.
How permissions are enforced
Permissions are checked server-side on every request: the API resolves your workspace role, and your project role inside a project, against the action you are attempting. Hiding a button in the interface is not a security measure — a request your role does not allow is refused, even if the URL is typed by hand.
Every member can see who belongs to the workspace and to a project. The list only names people — it never exposes response data.