Collaboration & roles
Delphi Studio is multi-tenant: each organization owns its studies, panel resources, and templates. Within a study, collaboration is controlled by role-based access so principal investigators can involve co-investigators and analysts without sharing credentials or over-exposing panelist identities.
Roles are enforced by the backend for every study read and mutation. Hiding an unavailable action in the interface improves usability, but it is not the security boundary. Purpose-bound panelist access and authenticated service workers, such as email delivery, operate under narrower permissions than researcher accounts.
Study roles
| Role | Typical user | What they can do |
|---|---|---|
| Owner | Principal investigator / study creator | Everything co-investigators can do, plus the owner-exclusive actions: manage collaborators, transfer ownership, and toggle organization-wide read access |
| Co-investigator | Senior collaborator | Full study operations: wizard edits where unlocked, panel, rounds, results, qual, reports, identity unmask, and the lifecycle actions — complete, terminate, archive, and delete |
| Analyst | Statistician or methods support | View access plus sensitive exports (results, analytics, qualitative workspace, export downloads) |
| Read-only | Advisor, funder liaison, or trainee | View study surfaces without mutating data or sending communications |
The study creator always resolves to Owner — creator status is permanent provenance and is not removed by role changes or ownership transfer. Sensitive actions (identity unmask, role changes, archival) are always audited.
Inviting collaborators
- Open the study Settings → Access (or equivalent collaborators surface).
- Pick a member of your organization and assign a role. Collaborators are selected from existing same-org accounts — there is no email-invitation flow for external users.
- Role changes are recorded in the audit trail.
Collaborators work inside the same study record — there is no need to export spreadsheets between team members for routine operations.
What stays restricted
Even owners and co-investigators normally see panelists as pseudonyms. Real identities live in a separate encrypted store; unmasking is a deliberate, audited action for operational needs (for example, correcting an email address), not routine review of ratings.
| Surface | Visibility |
|---|---|
| Ratings, comments, results | Pseudonyms only |
| Panel list (routine) | Pseudonyms + expertise / stakeholder fields |
| Identity unmask | Explicit action + audit event |
| Exports | Pseudonymized by default |
Browser storage is not an authorization boundary or a source of lifecycle truth. Recruitment, consent, COI, enrollment, launch, identity reveal, and amendment actions are accepted only through permission-checked server workflows. See Governed study record.
Organization context
| Concept | Meaning |
|---|---|
| Organization | Tenant boundary for users, studies, and shared templates |
| Study templates | Org-scoped methodology snapshots (taxonomy, policies, configuration — never item statements) for program-level standardization |
| Org-wide read access | A per-study toggle owners can enable so any organization member can view the study read-only (as org_member); the change is audited |
See Study design wizard for how templates seed new studies.
When the PI is unavailable
Co-investigators can continue most study operations without the owner’s credentials, including lifecycle actions such as archival. If a study has no active owner (for example, the owner account is deactivated), the study becomes read-only until ownership is resolved — plan collaborator roles before launch if continuity is critical.
Next steps
- Panel management — recruit and monitor the expert panel
- Audit trail — role changes and unmask events
- Governed study record — server authority and permission enforcement
- Delphi Platform lifecycle — how roles fit Design → Report