How a Permissions Matrix Gets Built, Step by Step
A look behind the scenes at how we map who can read, edit and approve files on shared drives and cloud storage, and turn that into a matrix a team can actually use.
Marcus Delgado · · 6 minutes to read
Starting with people, not folders
When we build a permissions matrix, the first meeting has nothing to do with software settings. We ask who touches the footage and what they need to do with it. An editor needs to write to a project folder, a producer needs to read finished exports, and a client contact may only need to approve a single review file. Writing those needs in plain sentences keeps the conversation honest.
Most teams already have a loose idea of this, but it lives in people's heads. One colleague remembers that a freelancer should not see the raw camera cards, another knows the archive folder is meant to be read-only. Our job in this first pass is to pull those habits onto one page so they can be checked against what the drive actually allows.
We usually sketch the roles on a whiteboard or a shared document before opening any admin panel. It takes under an hour for a small team, and it prevents the common mistake of copying settings from an old project without asking whether they still fit.
- List every role, including freelancers and clients
- Write what each role must do in one plain sentence
- Note anyone who changes role mid-project
Reading what the drive already allows
Next we look at the current state of the shared drive or cloud storage. This is closer to an audit than a redesign. We export or screenshot the existing folder permissions and compare them against the roles from the first meeting. The gaps are rarely dramatic, but they are usually specific: a former contractor still has edit rights, or a whole department can delete an archive folder.
We take care to record what we find without judgement. Permissions drift because projects are busy, not because anyone was careless. Noting each difference with its folder path, the person or group involved, and the access level gives the team a list they can work through calmly.
In the course, this step is practised on a sample project drive, which is why access to one is listed as a prerequisite. Learners inventory the permissions themselves and learn to spot patterns, such as access granted to individuals rather than groups, which tends to become unmanageable as a team grows.
- Export or capture current folder permissions
- Record path, person or group, and access level
- Flag access given to individuals instead of groups
Drafting the matrix itself
The matrix is a simple grid. Roles run down the side, folder areas run across the top, and each cell says read, edit, approve or no access. We keep the folder areas broad, such as raw footage, working projects, review copies, final exports and archive, so the grid fits on one page and can be understood at a glance.
Approve deserves its own note. On many productions, editing and approving are quietly treated as the same thing, which is how an unreviewed cut ends up in the delivery folder. Separating the two in the matrix makes the sign-off step visible and gives someone clear responsibility for it.
We draft the first version alone, then walk the team through it cell by cell. Expect a few corrections. A producer might point out that assistants need to write to the review folder, or that the archive should accept new files only through a single handover step. Those corrections are the point of the exercise.
- Keep folder areas broad enough to fit one page
- Use four levels: read, edit, approve, no access
- Give each approval step a named owner
Choosing groups over individuals
Once the matrix is agreed, we translate it into groups on the drive. Each role becomes a group, and people are added to groups rather than given rights one by one. This sounds like administrative tidiness, but it changes how the team behaves. A new editor joins the editors group and inherits the right access on day one.
Leaving works the same way in reverse. Removing someone from their groups closes their access in one action, instead of a hunt through dozens of folders. We have seen teams spend an afternoon finding every place a departed freelancer was named individually.
Group names follow the same naming discipline we teach for files: short, consistent and readable without explanation. A name like editors-working or producers-review tells the next administrator what it is for. Where a platform limits how groups can be nested, we adapt the matrix to what the platform supports rather than forcing a clever structure.
Testing before anyone relies on it
Before the new permissions go live, we test them. Someone in each role signs in or is simulated and tries the actions the matrix promises: open a raw clip, save a project file, move an export, delete something they should not be able to delete. The results are ticked off against the grid.
This is the least glamorous step and the one that catches the most. Inherited rights sometimes override a restriction, and a folder created last month may sit outside the group structure entirely. Finding these during a test is far cheaper than finding them when a deadline is close.
We also agree what happens when the matrix needs to change. Requests go to one named person, changes are noted with a date and a reason, and the grid is updated so it never falls behind reality. A matrix that is not kept current becomes another piece of folklore.
- Test each role against the actions the matrix allows
- Check inherited rights on recently created folders
- Name one person who approves changes
What the team keeps afterwards
At the end, the team has three things: the matrix as a one-page document, the groups set up on their drive, and a short note explaining how to add or remove someone. None of it requires specialist knowledge to maintain, which is deliberate. The goal is that a production manager can run it without calling us.
We usually suggest reviewing the matrix at the start of each new project and again when the team changes noticeably. These weeks of mid autumn are a common time to do it, as autumn projects wrap up and teams prepare for the quieter period before the next round of work.
Any hands-on changes to a live drive are scoped and agreed separately from the teaching and the guidance, so everyone knows who is touching what.
A permissions matrix is less about technology than about agreement. When roles, folder areas and approval steps are written down and tested, the shared drive stops depending on memory and goodwill. Start with the people, record what exists, keep the grid small, use groups, and test before relying on it. Done calmly, it gives the team one current answer to the question of who can do what with every file.
Send us a message
- Call us
- (505) 214-0873
- By email
- [email protected]