The idea that makes M-Files different is simple: instead of asking where a document is stored, M-Files asks what it is. That answer, the metadata, decides where the document appears, who can see it and what happens to it next.

The problem with folders

Is a signed contract with Acme Corporation filed under Contracts, under Acme, or under the 2026 project? In a folder tree it can only be in one place, so people make copies, and soon nobody knows which copy is current.

Metadata: describe, don't file

In M-Files, each document has a class, such as Contract, Invoice or Drawing, and the class defines its properties: customer, project, effective date, owner, status. When you save the contract, you fill in a short metadata card instead of choosing a folder.

Views: the same document, everywhere it belongs

A view is a saved question: "all contracts by customer", "documents assigned to me", "drawings of project Northwind by status". Because views read metadata, the Acme contract appears under Contracts, under Acme and under the project, as one document with one version history.

Lookups and value lists

Properties like Customer or Project are lookups: you pick a value from a list, so everyone spells "Acme Corporation" the same way. Lists can depend on each other, for example a sub-topic list that changes with the topic.

Metadata drives workflows and permissions

• A contract whose status is Draft can start a review workflow automatically.
• Documents of the HR class can be visible to HR only.
• A project's documents can follow the project's team.

Making metadata easy for users

Metadata only works if people fill it in. M-Files helps with metadata card rules, default values, templates and auto-fill from related objects. On a Mac, M-Client applies the same rules as M-Files Web, fills in a view's properties when you create a document inside it, and shows the metadata card when you drop a file onto the window or save from any app.

Want to see your own vault's views on a Mac? Start a free 15-day trial.