How We Designed Our Permission Levels (And Why)
Most VDRs offer too many roles or too few. Here's the design thinking behind ShareAndGo's four-level permission model.
Permission models are one of those things every data room vendor gets wrong in different ways. Too few roles and you can't express the permissions you need. Too many roles and admins get confused and start granting things by mistake. Here's how we settled on four permission levels — and the design thinking behind each.
The four levels
ShareAndGo has four permission levels for guest users:
- View Only (No Download) — Can see documents inside the viewer, but can't download, print, or save them. For the most sensitive content.
- Viewer — Can see documents and download them. Can't upload, edit, or manage access.
- Editor — Can see, download, and upload new documents. Can also rename and reorganise documents. Cannot delete other people's uploads.
- Admin — Everything, including managing access for other users. Reserved for internal team members.
Why not more
We initially considered a five-level scheme with a "Commenter" role between Viewer and Editor. The idea was that commenters could leave annotations without being able to upload. Early testing showed that commenters almost always also needed upload access (to share their own analysis back), so the distinction was artificial. We collapsed the roles.
We also considered per-document permissions — granting different roles on different documents within the same room. This is technically possible but creates a permissions management problem that gets out of hand fast. For the rare cases where it's needed, admins can create multiple data rooms with different scopes.
Why not fewer
The common mistake is treating "view" and "download" as the same permission. In practice they're very different. A document in a view-only context is far less likely to leak than a document that can be downloaded — the recipient can't forward it, can't print it, can't save it to a personal drive. For genuinely sensitive content, this distinction is the whole point.
Editor is similarly distinct from Viewer. An editor on a due diligence room is a trusted party actively contributing documents back. A viewer is an observer. Treating them the same means you have to either over-grant (give viewers edit rights) or under-grant (not let editors see everything), neither of which is right.
The default
When inviting someone new, the default is "Viewer." We deliberately don't default to "View Only (No Download)" because the friction cost of the viewer-only experience is high — people expect to download and print things, and when they can't, they often need to work through a support conversation.
Default to Viewer. Step up to Editor for people who need it. Step down to View-Only for the most sensitive content. This covers 95% of real use cases without needing a complex permission matrix.
The auditability
Every permission change is logged in the audit trail. Who granted what to whom, when, and on whose authority. This isn't decorative — it's the evidence you need if an access decision is ever questioned in court or by a regulator.