A file called “meal-plan-final-v3-NEW.pdf” leaves a teammate with two questions: where is it, and is it really the approved version? A shared filing system should answer both. Give each kind of work an agreed home, use filenames that identify what they contain, and make approval visible somewhere other than the filename.
For a team producing paleo recipes or digestive-health resources, the distinction matters. A recipe may pass through ingredient checks, testing, photography, editing, and publication. A reader’s food-and-symptom log, meanwhile, may contain sensitive personal details. Those files should not be handled the same way. The goal is a system that helps people find the right version without overwriting work or exposing records to people who do not need them.
Map the work before creating folders
Look at a few recent projects and list what the team actually creates: drafts, ingredient notes, tested recipes, images, approvals, published files, and archived material. Ask where people search first and which files they regularly have to request from a colleague. Those sticking points tell you more than a folder chart designed in isolation.
Choose a shared workspace as the primary home for team files, rather than relying on personal accounts or attachments. If the team needs a file for ongoing work, its only copy should not sit in one person’s downloads folder. Keep the structure shallow enough for a new teammate to follow. A small editorial team might use:
- Editorial Projects: active articles, recipes, and supporting assets
- Published Library: approved files the team may reuse or reference
- Operations: templates, schedules, and internal procedures
- Restricted: files that require narrower access
- Archive: completed work retained under an agreed policy
Within Editorial Projects, organize by project or content item if that is how work gets assigned. One recipe folder can hold its draft, testing notes, and image selections; separate top-level folders for each file format may scatter that work. Decide where a file belongs based on the task it supports, and write down the rule in a short guide.
Use filenames that answer the next person’s question
A useful filename identifies the subject, the file’s role, and, when relevant, its date or status. Pick a pattern people will actually use, such as Project_SpecificContent_FileRole_YYYY-MM-DD. One team might save RoastChicken_RecipeDraft_2026-04-15 and RoastChicken_TestNotes_2026-04-16. Those words are more helpful than a string of initials or “final-final.”
When dates matter, use year-month-day order so names sort chronologically. Choose one spelling for recurring terms, and avoid characters your tools handle inconsistently. A filename need not carry every detail: reliable tags or custom fields can hold the author, review status, or publication channel. Keep the file’s essential identity in its name, though, so it still makes sense when downloaded.
Set a revision rule as well. In a collaborative document with version history, one working file is usually easier to manage than a fresh copy after every edit. When an export is needed, label it with a date and status, and put only approved exports in the Published Library. “Approved” means an authorized person reviewed that specific version—not just that someone typed the word into its filename.
Make ownership and status visible
Folders show where work lives; they do not necessarily show what happens next. Give each active project an owner who keeps its files in the agreed location. That person does not have to write or review everything. They make sure handoffs are clear and drafts do not become disconnected from the project.
A simple project index can list the working-file location, current status, reviewer, and approved-file location. Use a few labels with defined meanings—Draft, In Review, Approved, Published, and Archived, for example—and avoid near-duplicates. If the team uses task-management software, link the task to the working file instead of uploading another copy whenever someone comments.
Templates help keep related information together. A recipe template might have sections for ingredients, method, testing observations, and editorial notes, with tested details clearly separated from tentative ideas. For health-related content, leave room to record claims that need checking and when they were reviewed. A tidy folder cannot tell you whether a nutrition claim is accurate or current.
Separate access from convenience
Not everyone needs access to every file. Recipe photos and public-facing drafts may suit a broad editorial group. Reader correspondence, food-and-symptom diaries, staff records, and contracts need tighter permissions. Grant access according to work responsibilities and review it when roles change. Setting a shared link to “anyone with the link” skips the decision about who should see sensitive material.
If a reader sends a symptom log, store it where only authorized people can access it, avoid copying it into chat threads, and follow the organization’s privacy and retention requirements. Keep identifying health details out of filenames and broadly visible project indexes. Dietary records are not a basis for team members to diagnose a reader. Encourage people to discuss persistent symptoms and dietary changes with a doctor; an exclusion diet should not replace medical care.
Make these checks part of the team’s routine:
- Use team-managed accounts and remove access when someone leaves a project.
- Check sharing settings before sending a file outside the team.
- Keep sensitive source material apart from publishable, de-identified content.
- Know who can restore a deleted file and how long recovery remains possible.
Plan for search, archiving, and recovery
Make searching predictable
Folders are only one way to find a file. Ask a teammate to locate a current draft, its approved version, and its supporting notes without help. If the search turns up several plausible “final” files, tighten the naming and approval rules. A short guide with two or three real examples may get more use than a long policy.
Keep copies to a minimum. Share a file’s location when someone needs to reference it, rather than duplicating it in another folder. If separate copies are necessary—say, an editable master and a web-ready export—give each a distinct role in its filename and show their relationship in the project index.
Archive deliberately
Move completed projects out of active folders on a predictable schedule, such as after publication and any planned corrections. Before archiving, check that the approved version, necessary supporting notes, and appropriate permissions are in place. Available storage is not a reason to keep sensitive records indefinitely; follow applicable requirements and the team’s retention policy.
Keep the archive searchable by preserving the project names used during active work. Make archived folders read-only where appropriate, so old files are less likely to be edited by mistake. If a published recipe needs a correction, create a clearly dated working revision and record which earlier approved file it replaces.
Know what can be recovered
Syncing helps people collaborate, but it is not necessarily a backup: an unwanted deletion or edit may sync as well. Check what version history, deleted-file recovery, and independent backups the team’s tools provide. Assign someone to test recovery, rather than assuming an enabled setting means it works.
Roll out a small system the team will use
Start with current work and the files people reach for most. Create the shared folders, choose a naming pattern, define what approval means, and move one representative project through the process. Note each moment when someone has to ask which file to use. Fix those problems before migrating years of older material.
After a short trial, put the rules on one easy-to-find page: folder locations, filename examples, permission requests, and what happens at publication. Assign someone to update it when the workflow changes. A monthly ten-minute check can catch stray downloads, duplicate exports, and projects that never made it to the archive.
Try the system on the next recipe entering review. Put its working draft and test notes in the project folder, name a reviewer in the index, and leave the Published Library alone until there is an approved export. Then ask a teammate to find the version ready to use. If they have to guess, you know exactly what to fix.
