Who Should Be Allowed to Edit, Review and Approve Your Shared Footage?
Daniel Whitfield answers the question production managers ask most often about shared drives: who gets read, edit and approve rights, and how to write that down so it holds up.
Daniel Whitfield · · 6 minutes to read
The question behind the question
The question I hear most in the permissions module is short: who should be able to edit what? It usually arrives after something has gone wrong, such as a final export overwritten by a well-meaning assistant, or a freelancer who still sees a client's drive months after the job closed. Nobody planned to be careless. The drive simply grew faster than the rules did.
Underneath it sits a second question, which is who decides. Permissions are not a technical setting first. They are a set of agreements about responsibility, and the software only records them. If a producer, an editor and a post supervisor each assume someone else approves final files, no folder setting will rescue the project.
So we start every permissions exercise with people and tasks rather than folders. Who ingests footage, who cuts, who signs off, who delivers, who archives? Once those roles are named plainly, the access rules mostly write themselves, and the arguments that remain are ones worth having.
Read, edit and approve are three different things
Most teams treat access as a single switch: you are either in the folder or you are not. That is where trouble starts. Reading a file, changing it and declaring it final are three separate powers, and a healthy setup hands them out separately. A director may need to read every cut and approve one, yet never touch a project file.
Read access is the widest circle and the safest. Edit access should be narrower and tied to a task, such as the editor working on the current cut or the colourist handling graded media. Approve is the narrowest of all, often a single person per project, because approval is what turns a working file into the one everybody trusts.
When you explain this to a team, use plain verbs on the page. Write that Maria can read, Jonas can edit, and the producer approves. Avoid vague words like manage or own, which mean different things to different people and invite exactly the confusion you are trying to remove.
- Read: view and copy files, no changes
- Edit: change working files within an assigned area
- Approve: mark a file as the current, signed-off version
Building a simple permissions matrix
The matrix is the tool we return to most. Put roles down the left side and project areas across the top: raw footage, working projects, exports, deliverables, archive. In each cell write read, edit, approve or nothing. One page, readable in a minute, and pinned where the team will actually look.
Fill it in with the team in the room, not alone at a desk. People notice gaps quickly when they see their own name against a cell. An editor will point out that nobody can currently approve a rough cut for review, or a producer will realise the intern can delete the raw folder.
Keep the first version small. Four or five roles and five areas are plenty for most teams. A matrix with thirty rows looks thorough and gets ignored. You can always split a role later, but a bloated chart rarely gets trimmed, and an unread chart protects nothing at all.
Shared drives and cloud storage rarely agree
Many teams run a local shared drive for editing and a cloud service for review and delivery. Each has its own vocabulary and its own defaults, and they seldom line up. A folder that is read-only on the drive may be fully editable through a cloud link someone shared in a hurry.
The practical answer is to decide which system is the source of truth for each area and apply the matrix there first. Raw footage might live only on the drive, with the cloud holding approved exports for clients. Then you review sharing links as a routine, rather than discovering an old one by accident.
Group-based access helps more than individual settings. Grant rights to a role group, then move people in and out as projects change. Setting permissions person by person feels quick on day one and becomes unmanageable by the third project, because nobody remembers why a given name has the rights it does.
- Name one source of truth per project area
- Grant access to groups, not individuals
- Review cloud sharing links at every project close
People who come and go
Freelancers, interns and external editors are where permissions quietly decay. They join for a week, get broad access because it is easier, and keep it long after they leave. The fix is dull and effective: every temporary person gets an end date written beside their name in the matrix when they are added.
At project close, run a short access sweep. List who still has rights, remove what the job no longer needs, and note the result in the handover record. This takes minutes when done at the time and hours when done a year later with half the context forgotten.
Equally, plan for the person who is away. If only one colleague can approve, a holiday stalls delivery and someone will start sharing a password. Name a deputy for approval in the matrix itself. That small line prevents most of the workarounds that undermine an otherwise careful setup.
Writing it down so it survives the next project
A permissions scheme that lives in one person's head dies when that person moves on. Keep the matrix with the project documentation, dated, with the name of whoever last confirmed it. When something changes, update the page and say why in a single line.
Teach it as part of onboarding rather than as a rule handed down. New starters should be able to answer three questions without asking anyone: what can I see, what can I change, and who signs off my work? If they can, the scheme is working, and if they cannot, the wording needs another pass.
Finally, expect a review. Early autumn is a natural moment, with summer projects wrapping up and new work starting. Compare the matrix with what the drives actually allow, and adjust whichever is wrong. The goal is not a perfect lock but a shared, honest picture of who holds which responsibility.
- Store the matrix beside the project documentation
- Date it and name who confirmed it
- Test it with a new starter's three questions
The answer to who should edit, review and approve is never a single name. It is a short, written agreement that separates reading, editing and approving, assigns each to a role, and gets checked whenever people or projects change. Start with one page, fill it in together, and revisit it at each project close. A modest matrix that everyone understands will protect your footage better than a complicated system nobody remembers.
Send us a message
- Call us
- (505) 214-0873
- By email
- [email protected]