The folder is not the problem. The problem is that six months later nobody can tell which of logo-final-v3-APPROVED-b.ai was the one the client actually signed off, including the person who made it.
The short answer
A design folder structure has one job that matters more than tidiness: telling you, later, what was delivered and what was superseded. Use one folder per project with numbered subfolders so they sort in working order — 01-brief, 02-working, 03-assets, 04-feedback, 05-delivered, 99-archive — and move superseded versions into 99-archive rather than renaming them. Delivered work is dated and never edited again. Then a workflow watching the project folder uses the Rename step to name incoming files from their contents and the Move step to file them, so the structure survives contact with a deadline.
Steps this uses
Before and after
As they arrive
After the workflow
The approved file is dated and isolated. The superseded ones are kept, not deleted, and not competing for the same name.
Setting it up
Numbers force the sort order to match the order you work in. Without them the folder lists alphabetically, which puts Assets before Brief and Delivered before Working — the reverse of how anyone thinks about a project.
The single most useful boundary. Anything in 05-delivered was sent to a client, is dated, and is never edited again. If it needs changing it comes back into 02-working as a new version.
Superseded work moves to 99-archive untouched. This is what kills the v3-FINAL-b problem: the version history is the folder, not the filename.
The Rename step names each incoming file from its contents and the Move step files it. Feedback and briefs arriving as email attachments get a home first through the Save a Copy step, since an attachment has none.
A folder listing sorts alphabetically whether you want it to or not. Numbering the stages makes the listing match the workflow, so opening a project shows you brief, working, assets, feedback, delivered in that order every time. It is a small trick and it is the reason the structure stays legible to someone who did not set it up — a contractor, a new hire, or you in eighteen months.
Every designer has tried to solve versioning in the filename, and every filename convention eventually produces final-v2-FINAL. The reason is that a filename has to carry both identity and status, and status changes. Moving superseded work into an archive folder separates the two: the name says what the file is, the folder says where it stands. Nothing has to be renamed when a new version supersedes it.
A workflow watching the project folder names incoming files from their contents and files them, in place, in the drive you already use. It does not decide that a design is approved — that is a human judgement and it is what the delivered folder records. Nothing here detects that an asset is missing from a set, and nothing compares versions to tell you what changed between them.
FAQ
One folder per project, with numbered subfolders so they sort in working order: 01-brief, 02-working, 03-assets, 04-feedback, 05-delivered, 99-archive. The important boundary is between working and delivered — anything delivered is dated and never edited again.
Stop encoding status in the filename. Move superseded versions into an archive folder untouched, so the name says what the file is and the folder says where it stands. Nothing needs renaming when a new version supersedes it.
No. Keeping them separate is what lets you answer "what did we actually send" months later. Delivered files are dated, isolated and never edited; if a change is needed, a copy comes back into the working folder as a new version.
Yes. A workflow can run on a schedule over a folder you point it at, so existing projects get the same structure rather than leaving you with a split between old and new work.
Keeping it is the part a workflow does, on every file that arrives.
Try The Drive AI Free5 GB free · No credit card required