Skip to main content
At the organization layer, Owners and Admins run the team: billing (Owners only), who gets invited, and how the catalog is set up. That’s account-wide. Can Edit / Can View on a Source and Owner through Viewer on a Collection are set per item when people share; Roles & Permissions covers how those two layers fit together. This page is the management side: what Owners and Admins can do on any Source or Collection in the org (add or remove people, see that something exists, hand off ownership), and where the line is for reading private content. Owners and Admins have powers the rest of the org doesn’t. Those powers exist because real organizations need them. Someone has to be able to add new members, reassign work when people leave, and clean up Collections that were set up wrong. What Owners and Admins can’t do is read private content without leaving a trail.

​
What Owners and Admins can do on any Source or Collection

Day-to-day, Owners and Admins are interchangeable. The only thing an Owner can do that an Admin can’t is billing and deleting the whole organization. Across every Source and Collection in the org, Owners and Admins can: The important line is the one on the right: Admins can see that a Collection exists. They can’t read what’s inside it. Seeing a Collection’s existence is part of managing the org. Reading the files inside is a separate, audited step. This matters for sensitive work: privileged legal communications, unreleased creative, personal archives. An Org Admin can reassign ownership of a Collection called Smith v. Jones: Privileged Communications without ever reading a word of what’s in it.

​
Reading private content: self-elevation

If an Admin genuinely needs to look inside a Collection (to investigate an issue, review what’s there before off-boarding, or help troubleshoot), there’s a deliberate path for that: they promote themselves into the Collection. This is called self-elevation. When an Admin self-elevates:
  1. They pick a role on the Collection (usually Admin, sometimes Editor or Viewer).
  2. 1Archive asks them to write a reason for the elevation before the change goes through.
  3. The elevation is written to the activity log permanently, along with the reason.
  4. The Collection’s current Owners get a notification that an Admin elevated themselves in.
The result: an Admin can’t look at private content quietly. Either they were already a member, or there’s a permanent record of them adding themselves, with a reason attached.
Self-elevation leaves a permanent mark. Use it when the work genuinely requires seeing the contents of a Collection, and write a reason that makes sense to the Collection’s Owners. “Off-boarding J. Smith” or “Investigating a broken link reported by client” is the right kind of reason. “Curious” is not.

​
Admin controls for Collections

Owners and Admins have org-wide settings that govern how Collections can be used across the team. Who can make Collections, and how they’re shared:
  • Allow Collection creation. When this is on, any member of the org (including Viewers) can create Collections from Sources they have access to. Turn it off to restrict Collection creation to Owners and Admins only.
  • Allow sharing Collections outside the org. When this is on, Collections can be shared with collaborators who aren’t part of the organization. Turn it off to keep all Collection sharing internal.
Which share links members can make: Share links come in three kinds: public (anyone with the link), password-protected (anyone with the link and a password), and private (invited members only). You control whether your team can create the two open kinds.
  • Allow public links. When this is on, members can create links that anyone with the URL can open, no password needed. Turn it off to block public links across the org.
  • Allow password-protected links. When this is on, members can create links that open only with a password. Turn it off to block password-protected links across the org.
Private links are always available and aren’t affected by these settings. When a kind of link is turned off, members see that option greyed out in the sharing panel, so they know why they can’t pick it.
Turning off public or password-protected links also deletes every existing link of that kind across your organization, right away. Anyone holding one can no longer open it. Reach for this when you need to lock sharing down fast.
These settings apply to the whole org. They’re not per-user. If you need tighter control over a specific person, adjust their org role instead.

​
Off-boarding someone who’s leaving

Removing someone who’s leaving has its own page, because it’s one of the few admin jobs people need to find in a hurry. It covers handing off or deleting the Collections they own, revoking every share and link they held, and what changes if you bring them back later.

Off-boarding

Remove someone who’s leaving in a single flow, and see exactly what access goes with them.
Self-elevation is the part of this page that comes up most often during an off-boarding. If you need to look inside a Collection before handing it over, to save the work or check what’s in there, promote yourself into it and write a reason. The rules above apply unchanged.