Why a shared drive isn't a document collection tool

You share a folder with a new client and it feels like the obvious move. One link, one place, drag and drop, done. You create subfolders — Bank, Payroll, Fixed Assets, Statutory — and email the client the link with a note: “please upload everything here.” For a week it looks tidy. Then the client uploads a file called scan.pdf into the top level, another into the wrong subfolder, a corrected version alongside the original with no way to tell them apart, and suddenly you are the one keeping order in a space that was supposed to keep it for you.

A shared drive is very good at one thing: holding files. Collecting documents is a different job, and the drive was never built for it.

A folder answers a question you didn’t ask

Reach for Google Drive, SharePoint, or Dropbox and you get storage. Storage answers exactly one question: does this file exist, yes or no. That is not the question collection turns on. The questions that actually matter are the ones a folder cannot answer.

• What did you ask for? A folder has no memory of the request. It holds whatever landed in it. It cannot tell you that you asked for eighteen things and fourteen have arrived, because it never knew about the eighteen. The list of asks lives somewhere else entirely — an email, a spreadsheet, someone’s memory.
• Is this the right version? Clients send corrections. A folder shows you accounts.pdf, accounts_final.pdf, and accounts_final_v2.pdf side by side and offers no opinion about which one you relied on. Three PDFs all named some variant of final is not an edge case. It is Tuesday.
• Did anyone review and accept it? In a folder, a file the client dumped an hour ago and a file your senior carefully reviewed and relied upon look identical. There is no acceptance state. Nothing distinguishes “raw upload” from “we checked this and it’s good.”
• What is still missing? The one thing you most need to know is the one thing a folder is worst at. Missing files are, by definition, not in the folder. The only way to see the gap is to compare the folder against a list the folder does not contain.

So you bolt a checklist onto the side. A spreadsheet, a shared doc, a tracker. And now you have two systems: the files in the drive and the list of what you wanted. They drift apart within days. A file arrives and nobody updates the tracker. The tracker says something is missing that is actually sitting in a subfolder nobody checked. Reconciling the two becomes a standing job, which is precisely the job you were trying to avoid.

The ask has to be the unit, not the file

The reason a drive cannot fix this by adding features is structural. Its unit is the file. A file has a name, a location, and contents, but it has no state, no history of intent, and no relationship to a request. To run collection you need the ask to be the thing you track, with files hanging off it.

That is what a Request Item is: one specific thing you asked a Client for, with its own status, its own conversation, and its own versioned files. The item remembers the request, because the request is the item. When you want to know what is outstanding, you read it from the item’s stored status rather than counting files in a folder. We wrote about why that design choice sits at the centre of the product in request items, not folders; this post is the plainer question a buyer asks first — why not just use the drive we already have?

Because once the ask is the unit, the four questions a folder cannot answer become built in:

• The request is remembered. Every item is an explicit ask, so “what did we request” and “what is still open” are properties of the record, not something you reconstruct.
• Versions are trustworthy. Files attach to the item with full version history. When the client sends a correction, it becomes the current submission, and the superseded file is retained as a previous attempt — never deleted, never confused with the version you relied on.
• Acceptance is a real state. Reviewing an item and accepting it promotes the Document to Evidence: a permanent part of the Engagement record, stamped with who accepted it and when. The distinction between a raw upload and an accepted, relied-upon file is now visible, because they are genuinely different states.
• Missing is readable. Because every ask is an item with a status, the gap is just the set of items still at requested. You are not comparing a folder to a list in your head.

Document, Evidence, and the state a drive can’t hold

The distinction a drive erases is the one audit work depends on. In a folder, an uploaded file is just a file. In a structured collection, there are two different things: a Document is a raw file a Client uploaded, not yet accepted; Evidence is a Document your Firm reviewed and accepted against a specific Request Item. Same bytes, entirely different standing.

This matters the day a file is questioned. Six months after fieldwork, someone asks which version of the fixed-asset register you relied on, and who signed off on it. A drive can tell you three files exist. It cannot tell you which one you accepted, when, or by whom, because it never recorded a decision — there was no decision to record, only a drag and a drop. A collection built on Request Items answers the question directly, because acceptance was a logged, attributable event and the previous attempts are still on file.

There is a control dimension too. Client documents are full of personal and financial data, and a broadly shared drive spreads copies and access in ways that are hard to reason about after the fact. A per-Client, per-Engagement structure with a real activity log gives you something you can actually stand behind. If that side of it matters to you, our security page covers how access and the audit trail are handled.

None of this means shared drives are bad. They are excellent at what they are for. But collecting client documents is not storage. It is a process with memory, versions, review, and a record you can defend — and that is what Clivanta is built to run.

A drive holds your files. It was never going to hold your process.