Organization roles (account-wide)
| Role | What they do |
|---|---|
| Owner | Runs the org. Handles billing, invites and removes people, and has the highest level of access on every Source and Collection. |
| Admin | Same as Owner for day-to-day work. The only things an Admin can’t do are billing and deleting the organization. |
| Editor | A regular contributor. Sees only the Sources and Collections they’ve been added to, or ones marked visible to the whole org. Inside those, can make, change, or remove things according to the share they were given. |
| Viewer | Read-only across the org. Sees only what they’ve been added to, and can never be given edit access on anything, even if someone tries to. Use this role for people who should look around but never change a thing. |
Dig into the details
Source permissions
How Can Edit and Can View on a folder pass down to everything inside
it, and what someone actually sees when their share sits deep in the tree.
Collection permissions
The four Collection roles (Owner through Viewer), what each one can do on
that Collection, and the two ways to share: direct to Shared with me or
through a folder.
Owners & Admins
What Owners and Admins can do that no one else can, and the workflow for
off-boarding someone who’s leaving.
The rules that apply everywhere
Three rules govern every access check in 1Archive. They apply to Sources, to Collections, and to the folders they live in.- Your org is a walled garden. Nothing inside your org is ever visible to someone outside it. No share, no setting, no link changes that.
- The highest role wins on the same item. If someone reaches the same folder, Source, or Collection through more than one path (a folder share, a direct share, and a “visible to the whole org” mark all at once), they get the most permissive of those grants on that item. Broader access (say, Can View on a parent folder) does not cancel out a stronger, more specific share (say, Can Edit on one Source inside it). 1Archive never quietly lowers access.
- Viewer is a strict permission boundary. If someone’s organization role is Viewer, they stay read-only everywhere. Even if you try to give them edit access on one Collection, the org-wide Viewer role wins. Shares can’t widen the boundary.
The server decides every permission check. The desktop app shows instant
results by keeping its own copy of the rules, but if it ever disagrees with
the server (for example, because someone’s access was taken away on another
machine), the server’s answer wins and the action is turned down.