Card outlining file sharing structure, group ownership, and restrictive sharing defaults. How to structure file sharing before the first folder gets created
Image: Productivity Software Reviews

Rules

Part of A file sharing service is really selling you its permission model

How to structure file sharing before the first folder gets created

File sharing setup decisions that are hard to reverse: the top level structure, group ownership, sharing defaults, naming, and five checks to run first.

The decisions that matter in a file sharing rollout get made in the first week, usually by whoever creates the first three folders. Everything after that is inheritance.

Most setup instructions describe buttons.

This page describes four choices that are expensive to reverse. They are where the top level boundaries sit, who owns a space, what sharing does when nobody thinks about it, and what happens to a space when its maker leaves.

What to take away

  • Settle the top level shape before anyone uploads anything. A folder structure is a permission structure wearing different clothes.
  • Give ownership to a group, never to a person. A space owned by an individual becomes unreachable the day that individual does.
  • Set the sharing default to the most restrictive setting you can live with, then loosen it deliberately where real work needs it.
  • Write down the four rules you settled on. An undocumented convention survives about two months.

Shape the top level first

There are only a few honest ways to divide the top level, and each one makes a different thing easy.

Top level division trade-offs

Divided by

Department
Onboarding is obvious
Project or client
Archiving in one move
Sensitivity
One rule per tier
Function
Retention follows function

Easy afterward

Department
Cross-department work
Project or client
People on eight projects
Sensitivity
Explaining the tiers
Function
Functional and confidential work

Painful afterward

Department
Project or client
Sensitivity
Function

Easy afterward

Department
Onboarding, because a new person's access is obvious
Project or client
Archiving a finished body of work in one move
Sensitivity
Applying one rule to a whole tier
Function, such as finance or legal
Retention rules that follow the function

Painful afterward

Department
Anything that crosses two departments, which is most real work
Project or client
People who sit on eight projects and lose track of where things are
Sensitivity
Explaining the tiers to anyone who did not attend the meeting
Function, such as finance or legal
Work that is functional and confidential at once

Pick one and let the second dimension live one level down. Two competing top level schemes running at once is the condition that produces four copies of the same document.

The reason this is worth an argument on day one is that the boundary you draw becomes the boundary access is granted at. Move a folder later and you move its permissions with it, into a parent that grants something different. That is how a document ends up visible to a group nobody intended.

Ownership belongs to a group

Every space needs an owner who can restore deleted content, change sharing, and hand the space to someone else. Make that owner a group with at least two members.

The alternative fails predictably. Somebody leaves, their account is disabled, and the space they created still holds the only copy of a contract. Recovering it becomes a support case rather than an administrative action. This is the same lifecycle problem the administration console exists to solve, and it is cheaper to prevent at creation than to repair at departure.

Two rules worth enforcing from the start: nobody creates a top level space without naming an owning group, and no group has fewer than two people in it.

Defaults you will not revisit

Whatever you set on day one is what most spaces will still be set to in three years. Decide each of these deliberately.

Sharing defaults to decide

  • Who a new link works for
  • Whether links expire
  • Who can add external people
  • Whether members create top level spaces
  • Deleted items window and recovery
  • Who a new link works for.Anyone with the address, anyone signed in to your organization, or named people only. The middle option is the one most teams actually want and rarely the one that ships as default.
  • Whether links expire.A link with no expiry is a permanent grant made by someone who was thinking about one afternoon.
  • Whether people outside the organization can be added at all, and by whom. If the answer is everyone, external sharing is not a policy, it is a habit.
  • Whether members can create new top level spaces.Usually no, or the structure you just designed lasts a fortnight.
  • What the deleted items window is, and whether an administrator can recover past it.

Access control is the part of this that has been written down properly elsewhere. The requirements in NIST SP 800-171 are framed for regulated work, but the underlying question they force, which is whether each grant is traceable to a stated need, is worth borrowing whatever your obligations are.

Naming, because search is not enough

Search finds a document when you remember a word in it. It does not help you notice that two teams are maintaining separate versions of the same policy.

A workable convention needs three things. A sortable date goes at the front or the back, plus a short subject and a status word for anything with a draft and a final state.

Resist longer schemes, because every extra field is one somebody will fill in wrongly. A naming rule followed 60 percent of the time is worse than none, since it teaches people to distrust the pattern.

Prove the setup before you announce it

Run these five checks with real accounts before anyone else arrives. They take an hour and they catch the failures that are embarrassing later.

Five pre-launch checks

  1. Sign in as member, test blocked access
  2. Share externally, open signed out
  3. Delete as member, recover as admin
  4. Disable test account, check group access
  5. Add to owning group, confirm access
  1. Sign in as an ordinary member and try to reach something you should not. Confirm you cannot, and confirm the message is comprehensible.
  2. Share a file externally to a personal address you control, then open it while signed out. Look at exactly how much the recipient can see and do.
  3. Delete a file as a member and recover it as an administrator. Note the window and write it down.
  4. Disable a test account and confirm the content it owned is still reachable by the owning group.
  5. Add someone to the owning group and confirm access appears without any further step.

The habit of testing rather than assuming is the same one that makes the rest of a rollout survivable, and the plain guidance in Start with Security is a decent short list to check your defaults against.

Fit it to what you already run

File storage rarely works alone. Documents get edited in a suite, discussed in chat, and attached to work items, so the choices above ripple outward.

Before you finish, check three things. Does your structure still fit your office suite setup? Do shared spaces map to the channels your team collaboration tool uses? Does anything wired in through connected applications reach the folders you expect, not the whole estate?

The wider category guide covers what these products differ on. This page is only about the hour of decisions that shapes everything you do inside one.

Common questions

How much structure should exist on day one?

Enough to hold the work you can name today, and no more. Empty folders created in anticipation get used for the wrong thing. Three to seven top level spaces is a reasonable range for most organizations; if you need twenty, the top level dimension is probably wrong.

Should we migrate old files during setup?

No. Set up the empty structure, prove it works, and let new work land in it. Old material is a separate exercise with its own reconciliation problem, and mixing the two means a failure in either one looks like a failure in both.

What if people ignore the structure?

They will, if the structure makes their work harder. Before enforcing anything, find out what they are doing instead and why. A shortcut that half the team invented independently is usually a design note, not a discipline problem.

Is a written policy worth the effort for a small team?

A page, not a policy. Four rules and the reasoning behind them. The value is not compliance; it is that the next person to join can be told what the pattern is instead of guessing it from the folder names.

More in Rules

Latest from Reporting Desk