Organizations and users
Roles, permissions and the rules that decide who can do what.
Who this is for
Organization administrators.
How access is decided
Every access decision asks two questions, and both must pass: does this person hold the permission, and does their role allow it in this context. A permission alone is not enough for a sensitive mutation, and a role alone never is.
What each role can do
| Role | Typically holds | Cannot |
|---|---|---|
| Founder / super admin | Platform-wide oversight, governance decisions | Bypass a governance approval that requires a second person |
| Organization admin | Programmes, projects, team, integrations, retention | Reach another tenant’s data at all |
| Research / M&E | Studies, sampling, analysis, qualitative coding, reports | Change retention policy or consortium access |
| Data analyst | Run analyses, read evidence, build reports | Create studies or configure integrations |
| Quality reviewer | Review evidence, confirm codings, promote results | Author the analysis they are reviewing |
| Enumerator | Assigned collection work, uploads, sync | Create a study, run an analysis, read another project |
Sessions and revocation
An SSO session is the same session object as a password session — created by the same code and revoked by the same code. Deactivating a user ends their ability to authenticate and refuses their existing sessions.
Tenant isolation
A request for another organization’s object returns not found, never forbidden. That is deliberate: “forbidden” would confirm the object exists, which tells you something about another customer’s data.
What this does not do
Stated here rather than discovered later
- There is no public sign-up. People are invited by somebody who holds the authority to invite them.
- An identity provider’s group claim never selects a role. Roles are granted in the platform.
- No tenant-administration permission can be granted to another organization, at all.