“Do we have the documents for this project yet?”
“They’re in Google Drive.”
“Where? What’s the file called?”
“It’s in the project folder.”
“There are several folders with similar names. Which one?”
“Probably the newest one. Wait—there’s a revised version too.”
If your team uses Google Drive, you may have had a conversation like this.
The file exists. It may even have been shared correctly. Google Drive has search. Yet the person who needs the file still cannot find it when they need it.
At first, I thought the answer was a better folder structure.
But the folder structure was only part of the problem.
Choosing the “right folder” every time is harder than it sounds
From an administrator’s point of view, the rules seem reasonable:
- Don’t create random folders.
- Use consistent project names and dates.
- Don’t leave business files in a personal My Drive.
- Upload finished files promptly.
The person uploading the file sees a different problem:
- Which folder is the official one?
- Why are there several projects with similar names?
- Am I allowed to put this file directly into that folder?
- What happens if I choose the wrong location?
- Should I wait until someone confirms it?
Sometimes the safest-looking option is to create one more subfolder “just in case.”
That is how folders called Final, Latest,
New, 2026_New, and For Review
begin to multiply. A folder created to avoid disrupting the existing
structure becomes another place for the next person to search.
And while someone is searching for the file—or waiting for an answer—the workflow stops.
Is that workflow actually working?
Put bluntly, administrators often want two things at once:
Don’t create your own folders. But don’t keep the file on your computer because you are unsure where it belongs. Upload it promptly—and when you do, make sure the right people receive the link.
That contradiction is difficult to solve with more rules and training alone.
Let people choose the project, not the folder
So I changed the question.
Instead of teaching every user how the folder structure works, what if the team had one place to upload project files?
The user would only need to:
- Search for the project name or Project ID.
- Select or drag and drop the file.
- Upload it.
The system would use a project directory to identify the correct Google Drive folder.
The user would not need to remember the folder hierarchy or create a new subfolder because the existing structure was unclear. Administrators could keep files inside the designated project folders without asking everyone to become a Drive librarian.
With a defined upload destination, the workflow no longer has to pause while someone confirms where the file belongs.
My first idea was to use Google Forms
Google Forms is an obvious place to start. Add fields for the project, the uploader’s name, and a file upload, and you have a simple document submission form.
For a small workflow with one destination, that may be all you need.
But project-based work soon raises more questions:
- Can the project dropdown stay synchronized with a project master list?
- Can each upload go to the correct project folder automatically?
- Can a folder be created when a new project is submitted?
- If a file with the same name already exists, can the user overwrite it or save a new version?
- Can we record who uploaded what and when?
- Can the right team members be notified automatically?
- Can someone find the file later by searching for the project?
- Can completed projects be removed from the active list?
Some of this can be built by adding Google Apps Script to Google Forms.
Build a no-code business app with AppSheet?
Another option is to turn the process into a business app with a no-code platform such as AppSheet.
I tried AppSheet too. It can do far more than I needed, but building one small workflow meant learning another product’s approach to data, views, permissions, and automation.
I was not trying to build a large business system.
I wanted something smaller.
Make the upload point the place to find files too
A submission form helps people send files, but it is not designed to help the team find those files later.
In real work, uploading is not the end of the process. Days or weeks later, someone else needs the document.
They may not remember the exact filename, but they often remember which project it belonged to.
That suggests a different kind of search: start with the project name or Project ID, then show the files in its linked folder. Instead of searching the whole of Google Drive or opening several levels of folders, the user narrows the search to the place where the file should be.
One place to upload. One place to find.
The same project-based entry point can reduce both “Where should I put this?” and “Where did that file go?”
A Google Sheet can become the project and folder directory
The workflow only needs a small amount of project data:
| Field | Purpose |
|---|---|
| Project ID | Identifies the project |
| Project Name | Gives users a recognizable name to search |
| Folder URL | Links the project to its Google Drive folder |
| Status | Marks the project as Active, Pending, or Inactive |
| Created At | Records when the project was added |
This is more than a settings table. It becomes an index of the team’s projects and Google Drive folders.
An administrator can open folders from the list, sort projects by name or status, and identify completed work that is ready to archive. Folders can be reorganized later when necessary.
A Google Drive folder normally keeps the same ID and URL when it is moved. If users access files through the project rather than memorizing the storage path, an administrator can reorganize folders by year, department, or archive status without teaching everyone a new hierarchy.
The structure does not have to be perfect before the team starts using it.
Share the file first. Organize the storage later.
For many day-to-day workflows, that order may be more practical.
I turned this approach into Flowless
Flowless is a small web app built with Google Sheets, Google Drive, Gmail, and Google Apps Script.
It includes:
- Project search by name or Project ID
- Drag-and-drop file upload
- Automatic routing to the linked project folder
- New-project submission and administrator review
- Overwrite or Version options for duplicate filenames
- Upload history
- Email notifications
- A Finder for locating files by project
- A project and folder management list
Flowless is not intended to replace a full document management system or a formal approval platform.
It is for teams that already use Google Drive and want to reduce a few recurring questions:
Where should I upload this?
Has it been shared yet?
Where can I find it now?
Build it yourself—or start with a working foundation
You can build a similar workflow yourself with Google Forms, Google Sheets, Google Drive, and Apps Script.
AI coding tools have made it much easier to get started. But combining project management, folder creation, duplicate handling, notifications, logs, search, and administration—and then testing the edge cases that appear when other people use the tool—still takes time.
Flowless is for people who would rather start with a working spreadsheet and the complete Apps Script source code.
You can:
- Use it as it is.
- Modify the code for your organization.
- Ask an AI coding assistant to help adapt it.
- Request customization for the parts you do not want to build yourself.
AI may eventually classify every file and select the correct destination automatically. If that happens, even the project-selection step could disappear.
The operational questions will remain: Which projects should be active? Who should be notified? Who submitted the file? How should duplicates be handled? When should a completed project be archived?
The goal is not to build a perfect system. It is to give people a clear place to share files before the trail goes cold.
If your team has been having the same “It’s in Drive—but where?” conversation, this approach may be worth trying.
Start with the working app, then adapt it to your team. Customization is also available for workflows that need something different.