A project brief sits in a shared folder, an updated version arrives by email, and someone edits a copy saved on their laptop. By the next meeting, the team is working from three different documents.
To organise files for remote teams without losing control, establish one approved shared workspace, clear access permissions, consistent filenames and regular reviews. Every important document should have a recognised location, a person responsible for it and an identifiable status.
For Australian teams working across home offices, client sites and different time zones, these habits make it easier to find the right file without waiting for a colleague to come online.
Folder structure
Start by deciding where shared work belongs. Choose an organisation-managed workspace that supports your team’s access and ownership needs.
Google’s shared-drive guidance explains that shared-drive files belong to the organisation and remain when a member leaves. Microsoft’s collaboration guidance identifies SharePoint as a place for team document storage, while OneDrive also supports individual work and selective sharing. Google Workspace Learning Center
The practical question is whether colleagues can keep using essential files when their creator changes roles or leaves the business.
Build folders around how your team works. A client-based business might organise by client and project. An internal team might use department and activity. Choose one approach and repeat it consistently.
Within each project, a simple structure could look like this:
| Folder | What belongs there |
|---|---|
| 01-Brief | Project scope, requirements and reference material |
| 02-Working | Documents and assets being developed |
| 03-Review | Material awaiting feedback or approval |
| 04-Approved | Approved deliverables and agreed records |
| 05-Archive | Superseded material that needs to be retained |
These labels are examples. Use fewer folders if the project is small, and add another level only when it serves a clear purpose.
Keep HR, payroll and other restricted records in a separately controlled area. A folder name such as “Confidential” does not establish an access restriction; permissions must be configured.
Before reorganising existing files, identify the current working copy and check who needs access. Trial the structure on one project, then confirm permissions and important links before moving more material.
Add a short guide explaining where new projects start, where approved work belongs and who can approve structural changes.
Permissions
Give people the access they need for their work. Someone reviewing a finished report may need less access than the colleague preparing it.
The Australian Signals Directorate’s small-business guidance recommends least privilege: providing the minimum permissions needed to perform a task. It also recommends reviewing access regularly, particularly when staff change roles or leave. CGA
Define a few understandable roles. Depending on the platform, these might include:
- Viewer: reads material without changing the shared file.
- Reviewer: adds feedback through comments or the platform’s review tools.
- Contributor: creates and edits working documents.
- Manager: controls membership, sharing settings and folder administration.
Role names and capabilities vary between services. Check the actual permissions rather than assuming a familiar label means the same thing everywhere.
Where supported, manage routine access through role-based groups. For example, a project group can cover the internal delivery team, while external reviewers receive access only to the material they need.
For restricted documents, prefer sharing with named recipients. Check the audience and permission level before sending the link. Use an access expiry date for temporary collaborators if your platform supports it.
Google’s file-access guidance shows why folder membership and direct file sharing both matter. Include both routes in your checks, especially after moving documents. Google Workspace Learning Center
An external designer may need campaign images and the approved brief, without needing internal budgets or unrelated client work. Set up their access around that task.
When a contract ends or a team member leaves, check group memberships, guest access, direct permissions and sharing links. Assign responsibility for this review so it does not depend on someone remembering later.
Naming conventions
Agree on a filename pattern that a new team member can understand. The name should explain what the file contains without requiring someone to open it.
For dated documents or exports, a useful example is:
PROJECT_document-type_YYYY-MM-DD_status.ext
For example:
TOPICA_content-plan_2026-11-02_review.xlsx
The WA Government’s document-naming guidance recommends a consistent date format and identifies YYYY-MM-DD as a way to keep dated documents in chronological order. wa.gov.au
Decide what the date represents. It might be the meeting date, reporting period or release date. Mixing these meanings makes otherwise tidy filenames difficult to interpret.
Also agree on a small set of statuses, such as:
- draft: being prepared.
- review: ready for feedback.
- approved: authorised for its intended use.
- superseded: replaced by a newer approved record.
Avoid names such as final-new, final-2 and use-this-one. They rely on context that may disappear when a file is forwarded or a colleague leaves.
For a live collaborative document, a stable filename such as TOPICA_content-plan.xlsx may be easier to manage. Keep editing the recognised shared file, and use dated names for exported snapshots when those snapshots are needed.
Microsoft documents how to restore earlier SharePoint versions when version tracking is enabled. Check your workspace’s settings and make sure the team knows how to use its version history. Microsoft Support
A filename containing “approved” is a label. Record who approved the document and when, using your review process or the platform’s available tools.
Review rules
Assign each project folder a responsible owner and a backup contact. Give them authority to resolve duplicate files, review access and decide what happens when the project closes.
Use a review schedule that suits the work. A practical starting point is:
- Monthly for active projects: check working copies, misplaced documents and access.
- At project completion: confirm approved deliverables, close temporary access and assess what should be retained.
- When someone changes roles or leaves: review their access and hand over responsibility for essential files.
These are suggested review points. Adjust the frequency for the sensitivity of the information and the pace of the project.
During each review, ask:
- Can a colleague find the current document without asking its creator?
- Are duplicate copies causing uncertainty?
- Do the intended users still have the right access?
- Are external sharing permissions still required?
- Is approval recorded for material marked as approved?
- Does retained material still have a business or legal reason to be kept?
Check retention requirements before deleting records. For organisations covered by the Privacy Act, the OAIC’s guidance on securing personal information explains the requirement to take reasonable steps to destroy or de-identify personal information that is no longer needed for a permitted purpose, subject to applicable exceptions such as legal retention requirements. OAIC
Moving information into an archive is not the same as deleting or de-identifying it. Retain what is required, restrict access appropriately and give archived material a future review date.
Keep a brief record of decisions: what was moved, which access was removed and who approved the change. Also document how files can be recovered and who is responsible for checking that process.
Start with one active project. Ask a colleague to locate its current brief, a contributor to edit the working document and an external reviewer to open only the intended deliverable. Use what you learn to refine the rules before applying them across the team.
