Workspaces for small teams: roles, invites and who owns what

Small teams usually start sharing files the way two people do: someone creates a folder in their personal drive and shares it with everyone else. It works for a while. Then the person who created the folder goes on holiday, or changes jobs, or deletes something they thought was theirs, and the team discovers that all their files were technically one person’s files all along.

A workspace fixes this. It is a space the files belong to, rather than a person, with members and roles. This article explains how workspaces work, how the roles map onto real jobs, and how to set one up without overthinking it.

The core idea: files belong to the workspace

In a personal drive, you own your files. If you share a folder, the other people have access to your folder. Remove them, and they lose access; remove yourself, and the folder is still yours.

In a workspace, the workspace owns the files. Members have access according to their role. When a member leaves, the files stay exactly where they are, because they were never the member’s files. This is the single most important property and the reason teams should use workspaces rather than a web of individual shares.

With Onlinedrive, workspaces are included from the Professional plan up. Professional gives you 3 workspaces with 5 members each; Business gives 10 workspaces with 20 members each; the larger plans scale from there up to Enterprise at 40 workspaces and 100 members. The pricing page has the full list.

The four roles

Onlinedrive workspaces have four roles. Most team tools have something similar, with different names.

Owner. Created the workspace, or was handed it. Can do everything, including deleting the workspace and changing other people’s roles. There should be one, and it should be a person who is not going anywhere, or a shared business account that the business controls.

Admin. Can manage members and settings and work with all the files. This is the role for whoever actually runs the team day to day. The owner might be the company director; the admin is the office manager.

Editor. Can add, change, move and delete files. This is the default for team members who do the work. If in doubt, make someone an editor.

Contributor. Can add files and work with their own, but has more limited rights over others’ work. This is the role for people who need to put things in without being able to reorganise or remove what everyone else has done: a new starter in their first weeks, a contractor delivering into your space, a client supplying source material.

A useful way to think about it: owner and admin manage people, editor and contributor manage files, and the difference between editor and contributor is whether they can affect other people’s files.

Mapping roles to a real team

Consider a five-person design studio.

• The founder is the owner. She rarely touches the files but she is the one who should be able to recover the workspace if anything goes wrong.
• The studio manager is an admin. He invites new people, removes leavers, and is the person everyone asks when they cannot find something.
• The two designers are editors. They create, rename, move and delete freely within projects.
• A freelance illustrator who delivers artwork most months is a contributor. He drops finished files into the project folder. He does not need, and should not have, the ability to restructure or delete the studio’s work.

Nobody has more access than they need, and nobody is blocked from doing their actual job. That is what good role assignment looks like.

Inviting people

Members are invited by email. They receive an invitation, accept it, and the workspace appears in their account alongside their own drive. You pick their role when you invite them and can change it later.

A few practices that save trouble:

Invite to a work email where possible. If someone leaves, their work email is usually deactivated, which is a natural moment for their access to end too.

Start people as contributors if you are unsure. Promoting someone to editor after a month is one click. Undoing a well-intentioned folder reorganisation by a new starter is an afternoon.

Keep the member list honest. Every quarter, look at who is in each workspace. Anyone who has not been involved for months should probably be removed. Access that is no longer needed is a risk with no benefit.

When someone leaves

This is where workspaces earn their keep. When a member is removed:

• Every file they added stays in the workspace, in the same place.
• Their access ends immediately.
• Nothing else changes for anyone else.

Compare that with the shared-folder approach, where a departing person’s folder either goes with them or has to be hurriedly copied out before their account is closed. With a workspace, the departure is an admin clicking Remove, and that is the whole procedure.

If the person leaving is the owner, transfer ownership before they go. The owner role is the one thing that does need a handover.

Structuring the workspace

A workspace is a shared drive, and the same organising principles apply as to any drive. A structure that works for most small teams:

• Projects, with one folder per project, each containing the same subfolders (Brief, Working, Final).
• Operations, for policies, templates and supplier information.
• Shared with clients, the only place from which external share links are made, so anyone can see what outsiders might be able to reach.
• Archive, where finished projects go.

Folder structures that still make sense a year from now goes into the detail.

One habit worth enforcing: nobody works from their personal drive on team projects. If it is team work, it goes in the workspace from the first draft. Otherwise you are back to files that disappear with people.

Several workspaces or one?

Plans include more than one workspace for a reason. Separate workspaces make sense when the groups of people are genuinely different:

• One per client, when each client has their own staff who need access and must not see other clients’ work.
• One for the core team and one for a wider pool of contractors.
• One for the business itself (HR, finance, legal) with a small membership, separate from the project workspace everyone is in.

Separate workspaces do not make sense just to separate projects. Use folders for that. A workspace is about who, not what.

Sharing from a workspace

Files in a workspace can be shared externally the same way as personal files: a public link with optional password, expiry and download control, or a named share by email. Admins and editors can do this.

For teams, the useful rule is to keep external sharing visible. If all client-facing links are made from one folder, anyone can review what is live. Expiry dates on every external link mean that even forgotten links switch themselves off. Password-protected and expiring links covers the settings.

Setting one up: a checklist

1. Decide who the owner is. Ideally a role or a business account, not whoever happens to be setting it up.
2. Create the workspace and name it for the team or client, not the project.
3. Create the top-level folders before inviting anyone, so people arrive to a structure rather than an empty space.
4. Invite the admin first, then editors, then contributors.
5. Move existing shared folders into the workspace, and delete the old personal shares once everyone confirms they can see the new location.
6. Put a quarterly reminder in the calendar to review members.

Next step

If your team currently works from folders in someone’s personal drive, list those folders and who they belong to. That list is your migration plan. Create one workspace, move the most active folder in, and invite the people who use it. Do the rest over the following weeks. The knowledge base has the step-by-step for creating workspaces and changing roles.