Most access problems are not breaches. They are the accumulated result of a hundred small, reasonable decisions — share this with him, add her to that — that nobody ever wrote down and nobody can now reconstruct.
The question that exposes the problem
Pick one person who left in the last year. Can you say, in under a minute, exactly which records they still have access to?
Most teams cannot, and the reason is structural rather than careless. Sharing happened one file at a time, over months, through whichever channel was convenient. There is no list because no list was ever produced — access was a side effect of a conversation.
Everything below is aimed at making that question answerable, because a permission model you cannot audit is not really a permission model.
Share the container, not the contents
File-by-file sharing feels precise. In practice it is the thing that guarantees drift: a new document lands in the folder next week, nobody shares it, and half the team is working from a set of records the other half cannot see.
Sharing at the folder level and letting permissions inherit inverts that. Access becomes a property of where a record lives rather than a decision someone remembered to make. Filing the document correctly is the same act as granting the right people access to it.
This only works if the folder structure matches how the work is actually divided:
- One folder per client, site or project — the natural unit people already talk in.
- Nest for detail, not for hierarchy. A folder per year inside a client is useful. A folder per department inside a client is usually someone drawing an org chart.
- Anything shared broadly goes in its own branch. Do not bury a company-wide reference document three levels inside a client folder — you will end up sharing the whole branch to reach it.
How Filio does it
Share a folder and everything inside it goes with it, including anything added later. When a folder is too much, you can share a single document instead. See how sharing works.
Read and edit are different questions
The default instinct is to grant edit access because it avoids a follow-up request. It is also how a reference record ends up with three conflicting versions of the same row.
A rule of thumb that holds up:
- Edit for the people whose job is to produce the record. Usually a small number, often one.
- Read for everyone who needs to act on it. This is almost always the larger group, and read access serves them completely — they see live data, they just cannot change it.
Read-only is not a lesser form of access. For most people it is the correct one, and granting it freely is what stops the requests that lead to over-granting.
Revoking has to be as easy as granting
Every system makes sharing easy. The ones worth trusting make removal equally easy, and make it take effect properly.
Three things to verify before you commit:
- Can you see everything one person has access to, in one place?Not “who can see this document” — the reverse. This is the view that makes an offboarding checklist possible.
- Does revoking reach an offline copy? If the app works offline, someone removed today may still be holding a local copy. It should disappear at their next sync rather than persisting indefinitely.
- Is the rule enforced below the interface? Hiding a record in the UI is not the same as the server refusing to return it. Ask any vendor whether permissions are enforced at the database level. It is a fair question and the answer is revealing.
An offboarding checklist worth keeping
On someone’s last day: open the list of what they have been given, remove it, then open the list of what they shared with others and reassign the owner. The second half is the one everyone forgets, and it is how records end up orphaned.
Keep the setup boring
Seat provisioning, invite codes and approval flows all sound like governance. Mostly they are friction, and friction is what pushes people to work around the system — the shared login, the exported copy on someone’s personal drive, the screenshot sent over chat.
Adding a colleague by email address and picking a role is enough for most organisations. The control that matters is not how hard it is to add someone; it is whether you can see, at any moment, what they can reach — and take it back in one action. See how teams are set up.
One caveat if your team works offline
Offline-capable apps hold real copies of data on real devices. That is the point, and it changes the shape of the access question: a permission is not fully revoked until the device that holds the copy comes back online.
It is a good trade for teams that work in places with no signal — but it makes device policy part of your access policy. More on how offline sync works.
Filio shares folders with inherited permissions, read or edit per person, and shows you everything you have handed out in one list.
Get it on Google Play