← All postsHow-to

File metadata: finding documents without remembering where they are

File metadata is the third way to find things, after names and folders. Which fields earn their place, who fills them in, and why most tagging schemes collapse.

How-toF

There are three ways to find a document: remember its name, remember where it is, or describe it. The first two break as volume grows — names drift, folders reflect an organisation that has since changed. File metadata is the third route, and it is the only one that survives both, because it describes the document rather than its location.

Which file metadata fields earn their place

  • The matter it belongs to — client, project, case. This single field answers most real searches.
  • Document type: contract, invoice, report, certificate. Coarse categories, not a taxonomy.
  • Status, where documents have one: draft, signed, superseded. Superseded is the field that prevents the worst mistakes.
  • An owner, so there is somebody to ask.
  • Dates that matter beyond creation — effective date, expiry, review date.
  • Retention category, which is what makes deletion later a decision rather than an argument.

Why tagging schemes collapse

They collapse because they are optional and open-ended. A free-text tag field produces "contract", "Contract", "contracts" and "agreement" within a month, and search against it becomes unreliable, which teaches everybody to stop using it. The fix is unglamorous: a short closed list of values per field, applied at upload rather than retrospectively, and fewer fields than you think you need. Five fields people fill in beat fifteen they skip.

Capture metadata at the moment of filing, ideally as part of the upload rather than as a separate step afterwards. Retrospective tagging projects have roughly the same success rate as retrospective documentation projects, which is to say they are abandoned at about forty percent.

Who fills it in

  1. Derive whatever you can rather than asking — the uploader, the date and often the matter are already known.
  2. Ask for the two or three fields that cannot be derived, at the moment of upload.
  3. Make the values a list, not free text, so the same thing is always described the same way.
  4. Let the rest be optional and accept that optional fields will mostly be empty.
  5. Review the vocabulary annually and merge the values that mean the same thing.

What it buys you

Three things that folders cannot. Finding every document of a type across all matters — every certificate expiring this quarter, regardless of which client folder it sits in. Knowing which version is current without opening files. And answering a retention question by filter rather than by reading, which is the difference between a half-hour task and a project nobody starts.

Ettex Storage supports the fields alongside the files — matter, type, status, owner, expiry and retention category — with values picked from a list rather than typed. Combined with a file naming convention and a sensible folder structure it gives three independent routes to the same document, which is what makes finding things reliable rather than lucky.

Frequently asked

How many metadata fields should there be?

Few enough that people fill them in — usually three to six, with values chosen from a list. Fifteen optional fields produce fifteen mostly-empty columns.

Free text tags or fixed values?

Fixed values for anything you intend to search or filter by. Free text drifts into near-duplicates within weeks and quietly makes search unreliable.

Is it worth tagging old documents?

Usually only the ones you still use. Retrospective tagging of an entire archive is the classic abandoned project; tag going forward and backfill only what gets opened.

MI
Written by Maria I.

Part of the Ettex team — writing about product, engineering and the future of work.

More posts
Get the best of the Ettex blogProduct news, guides and tips — straight to your inbox, no spam.