Collection Permissions

A Collection is a named set of files a team works on together: a project, a client matter, a campaign, a reel. Files inside a Collection can live on any Source, anywhere in your catalog. The Collection is what holds them together. Your organization role (Owner, Admin, Editor, or Viewer) still applies account-wide; see Roles & Permissions. What this page covers is the second layer: the Owner, Admin, Editor, or Viewer role someone has on a specific Collection. The org role sets the permission boundary for Sources, but Collections work differently. A Viewer in the org can create their own Collections from any Source they have access to, and can make changes within those Collections. What they can’t do is edit Sources directly. Collections have more moving parts than Sources, so they use four roles instead of Source-style Can Edit / Can View. And unlike Sources, a Collection can be shared with someone without showing them any of the folders around it.

​

The four Collection roles

Every person on a Collection has one of these roles. Roles are listed from most to least powerful. A few notes on what each role is for:

• Owner runs the Collection and can delete it or hand ownership to someone else. A Collection can have more than one person as an Owner.
• Admin does everything an Owner does except deleting or handing off. Use this for co-leads or people who need to manage the member list.
• Editor is the day-to-day role: adding files, leaving comments, changing what’s in the Collection.
• Viewer is for clients, stakeholders, or anyone who should see the work but not touch it.

​

The two ways to share a Collection

Collections can be grouped into folders, the same way Sources can. That means there are two places you can share from:

• Share the Collection itself. Pick people or teams. For people, choose Owner, Admin, Editor, or Viewer in the admin console; the desktop uses Admin, Editor, or Viewer and a separate action to hand ownership off. For teams, choose Admin, Editor, or Viewer. They see the Collection as a shortcut in their Shared with me view. They don’t see the folder the Collection lives in, or any other Collection nearby.
• Share the folder the Collection is in. The share covers every Collection inside that folder, now and in the future. The folder shows up in the recipient’s navigation, and they can open anything in it with the role you chose.

Pick by the outcome you want:

• Share the Collection when the person should see only that one thing. Common for client shares and one-off collaborations.
• Share the folder when the person should see everything in a grouping, including Collections you haven’t made yet. Common for team folders where new work lands all the time.

​

What “Shared with me” looks like

When you share a Collection itself, the recipient finds it in Shared with me, whether you added them individually or through a team. They see the Collection with the role that applies to them, without its surrounding folders or neighboring Collections. This is what makes Collection sharing different from Source sharing. With a Source, the recipient can always walk up the folders to the share. With a direct Collection share, the folder tree is invisible. The Collection is the whole world they see.

​

When folder structure still matters

If you share at the folder level instead, the same rules as Sources apply. The folder shows up in the recipient’s navigation, every Collection inside it is covered by the share, and the role you chose applies to all of them. Any Collection added to that folder later is automatically covered, too.

​

How overlapping shares combine

A person can have access through an individual share, a team, or a folder containing the Collection. Individual shares take priority over team shares, even when the individual role gives less access. For example, Editorial has Editor access to Holiday Promo. Invite Rhea individually as a Viewer and, once she accepts, she is a Viewer there. Remove that individual share and she returns to Editor through Editorial. Folder shares count too. If someone has individual shares on both a Collection and its containing folders, the highest of those individual roles applies. A lower individual role on the Collection doesn’t reduce a higher individual role from a folder. If they have no individual share, the highest role from their teams applies: Admin, then Editor, then Viewer. Making a Collection or its containing folder visible to the organization gives org members at least Viewer access. It never reduces anyone’s role. An org Viewer can still be an Editor or Admin on a Collection; they still can’t change Sources directly.

​

Share with a team

A team is a named group of people in your organization, such as Editorial or Production. Organization Owners and Admins manage teams created in the admin console. Teams synced from your company’s directory are managed there by your IT team. Sharing with a team gives its current and future members access without inviting each person separately. In the desktop app, you can manage team shares if you’re an Owner or Admin of the Collection or its organization. Switch to the organization that owns the Collection; the team must belong to that organization too. The admin console’s Collection team controls require Owner or Admin access to the Collection itself. A team can never be the Owner. Everyone on the team gets the chosen role until the team is removed or they leave it, unless an individual share sets their role instead. People who join the team later get access too, once they have joined 1Archive. To set one person’s role individually, choose Users and invite them even if their team already has access. For teams shared on this Collection, the dialog can show which team role the invitation replaces when accepted. Team access from containing folders may not appear in that hint. The overlapping shares rule still applies to shares through folders.

​

Remove a team or a person

Remove a team from Teams with access to end the access that share gave everyone on it. This keeps the team itself intact. Members keep any access they have through another team, an individual share, or organization-wide visibility. Removing a person from Users removes their individual share. The confirmation can show access they keep through a team shared on this Collection, but it doesn’t list team access from containing folders. Check folder shares too before assuming that removal ends their access. To end one person’s team access, remove them from that team. For a team created in 1Archive, an organization Owner or Admin can do this in the admin console. For a team synced from your company’s directory, ask your IT team to remove them from the group there. This also ends the access that team gives them on other Collections. If your only access comes through a team, you can’t use Leave to leave that Collection on its own. Leaving the team ends the access it gave you. Other shares can still give you access.

​

Handing off a Collection

Use the ownership transfer action to name a new Owner and hand over your role in one save. A Collection can have co-owners, but it must always keep at least one Owner. If you’re its last Owner, you can’t give up that role before someone else takes it.