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. This page walks through both halves: what these roles can do on any Source or Collection that others can’t, and how to use those powers responsibly when someone leaves.

​
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:
They canThey cannot
See that a Source or Collection exists: its name, where it lives, and who’s on itRead the files, comments, or links inside a Collection they’re not a member of
Add or remove members on any Source or Collection
Hand off ownership of a Collection to someone else
Change a Collection’s name, folder, or who can see it
Delete a Collection
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 is a powerful action. 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

The messiest case for any permissions system is an employee leaving the company. An admin needs to be able to reassign that person’s work without first being invited into everything they own, and the reassignment often has to happen before the employee is told they’re leaving. The workflow 1Archive is built for:
1

Find the Collections they solely own

In the member’s profile, open the Collections owned section. 1Archive shows a filtered list of Collections where this person is the only Owner. These are the ones that need a new Owner before you remove the person.
2

Promote a replacement Owner, silently

For each Collection on that list, add a replacement Owner alongside the departing user. The change is silent by default. The departing user keeps their access and isn’t notified. This is how you transfer ownership before HR delivers the news.
3

Optional: audit the contents

If you need to look inside a Collection before off-boarding (to save the work, check what’s there, or follow a policy), self-elevate into it. This adds the audit entry described above.
4

Remove the departing user's access

Once HR has delivered the news, make a second pass through the same list and remove the departing user from every Collection and Source. Because you named a replacement Owner earlier, nothing is left without one.
5

Delete the profile

When you delete the account, the Collections and Sources the person worked on stay intact. Their name is kept on the things they created, for audit, but their name alone never grants anyone access.
The same pattern works for Sources, with one simplification: Sources don’t have a single-Owner requirement, so you can remove a departing user’s access in one pass without lining up replacements first.
1Archive won’t let you delete an account that’s still the only Owner on any Collection. If you try, the app will point out the Collections that need a new Owner first. The tooling exists to prevent orphaned work. Line up replacements before the final delete, and the rest is one click.