File Permissions and Access Control for Teams: A Practical Guide
Most teams start with everything shared. One folder, everyone has edit access. It works for three people. By the time you reach ten, someone has accidentally moved a client folder, deleted a file that was not theirs, or shared a link they should not have.
The typical reaction is to lock everything down. Suddenly nobody can access what they need without asking an admin. Productivity drops. People start emailing files to each other again. You are back where you started.
The right approach is somewhere in between: structured permissions that match how your team actually works, without creating a bottleneck every time someone needs a file.
How Role-Based Permissions Work
The Drive AI uses five workspace roles. Each role maps to a clear set of capabilities. There is no per-file permission configuration needed for most teams — the role handles it.
The Five Roles
Owner
- Full control over everything in the workspace
- Invite and remove members
- Change any member's role
- Manage billing and subscription
- Connect and manage integrations (Gmail, Outlook, Slack, Teams, cloud storage)
- Archive or delete the workspace
- Access the complete activity log
- Every workspace has exactly one owner
Admin
- Invite and remove members
- Manage integrations and approve connection requests
- Access workspace settings and activity log
- Access email blocklist and sync history
- Cannot change member roles
- Cannot delete the workspace
Member
- Create, edit, and delete files
- Access workspace settings
- Cannot manage other members
- Cannot connect integrations or access admin-level settings
Viewer
- Read-only access to workspace files
- Cannot create, edit, delete, or manage anything
- Cannot access workspace settings
Guest
- Same access as Viewer — read-only
- Intended for external collaborators with limited scope
Permission Matrix
| Capability | Owner | Admin | Member | Viewer | Guest |
|---|---|---|---|---|---|
| View files | Yes | Yes | Yes | Yes | Yes |
| Create/edit/delete files | Yes | Yes | Yes | No | No |
| Invite members | Yes | Yes | No | No | No |
| Remove members | Yes | Yes | No | No | No |
| Change member roles | Yes | No | No | No | No |
| Manage integrations | Yes | Yes | No | No | No |
| Access settings | Yes | Yes | Yes | No | No |
| Access activity log | Yes | Yes | No | No | No |
| Manage billing | Yes | No | No | No | No |
| Archive/delete workspace | Yes | No | No | No | No |
Setting Up Permissions for Your Team
Step 1: Identify Your Roles
Before inviting anyone, map your actual team structure to roles:
- Department leads or project managers → Admin. They need to invite team members and manage integrations, but do not need billing access or the ability to delete the workspace.
- Team members doing daily work → Member. They create and edit files but do not need to manage people or settings.
- Clients, stakeholders, or external reviewers → Viewer or Guest. They need to see deliverables but should not modify anything.
- You (the workspace creator) → Owner. You handle billing and have final authority.
Step 2: Invite with Roles
Invite members individually or in bulk. You can paste a comma-separated list of emails and assign roles. Every invitation includes the role, so people have the right access from the moment they join.
Pending invitations are tracked separately. You can change the assigned role before someone accepts — useful if you initially set the wrong permission level.
Step 3: Require Integration Approval (Optional)
For team workspaces, admins can require approval before a member connects a new integration. This prevents unauthorized Gmail accounts, Slack workspaces, or cloud storage services from syncing into the team workspace.
When approval is required, a member's integration request goes to an admin or owner for review. They can approve or reject with a reason.
The Activity Log: Accountability Without Micromanagement
Permissions prevent unwanted actions. The activity log tells you what actually happened.
Every action in a workspace is recorded:
- File operations: upload, create, edit, delete, move, rename, copy, restore
- Access events: view, download
- Sharing changes: share, unshare, permission modifications
- Integration activity: import from or export to connected services
- Publishing: publish or unpublish files
Each log entry includes who did it, when, which file was affected, the file path, and whether the action succeeded or failed. IP addresses are recorded when available.
Filtering and Stats
The activity log supports filtering by:
- Date range
- Action type (uploads only, deletions only, etc.)
- Actor type (user actions, AI actions, system actions)
- Specific user
Aggregated stats show total activities, breakdown by action type, and most active users. This is useful for compliance reporting, security reviews, or understanding team usage patterns.
Why This Matters
Without an activity log, investigating file issues requires asking around: "Did anyone move the Henderson folder?" "When was this last updated?" "Who shared this externally?"
With an activity log, you filter to the file in question and see the complete history. No detective work. No accusations. Just facts.
Common Permission Patterns
Agency with Client Access
- Agency owner → Owner
- Account managers → Admin (invite clients, manage integrations)
- Designers, writers, developers → Member (create and edit deliverables)
- Clients → Viewer (review deliverables, cannot modify)
Law Firm with Support Staff
- Managing partner → Owner
- Partners and senior associates → Admin
- Associates and paralegals → Member
- Clients → Viewer (view case documents only)
Startup Engineering Team
- CTO → Owner
- Engineering leads → Admin (manage team access, integrations)
- Engineers → Member (full file access)
- Product managers, designers → Viewer (reference documentation without modifying)
Consulting Firm
- Firm principal → Owner
- Project leads → Admin (per-project workspace)
- Consultants → Member
- Client stakeholders → Viewer
Workspace Archiving for Completed Projects
When a project ends, archiving the workspace switches it to read-only mode. All files are preserved. No one can create, edit, or delete anything. The subscription pauses.
This is better than deleting because:
- Files remain accessible for reference or compliance
- The activity log is preserved
- The workspace can be unarchived if the project resumes
Only the owner can archive or unarchive a workspace.
Getting Started
- Create a team workspace
- Map your team members to the five roles
- Invite everyone with the correct role
- Enable integration approval if you want to control connected services
- Review the activity log periodically for awareness
Permissions should match how your team works, not create friction. Set them up once, adjust when roles change, and let the activity log handle accountability.
Share it with your network
