# Workspace Permissions That Scale: The 5-Role Setup Every Agency Needs

> Most teams either give everyone admin rights or get into a tangled custom-roles mess. Here is the 5-role permission model that scales from a 3-person agency to a 50-person team without rewrites.

By The Zinx OS Team on 2026-05-04.

There is a predictable arc to how growing teams handle permissions inside a shared workspace.

In month one, everyone has admin access. The team is three people, you trust everyone, and roles feel like overkill.

In month nine, you have hired three more people, taken on two clients with NDAs, and noticed that a junior designer can technically see confidential client budgets on every project. You spend a weekend retrofitting roles and break two integrations in the process.

In year two, you have a permission matrix with 47 custom roles, none of which the team can remember the meaning of. New hires get given "the role we use for designers, I think" and discover three days later they cannot do something they need to.

The fix is to start with five roles, not zero and not forty-seven, and to bake those roles into how you set up every new workspace from day one. This guide is the playbook.

## The five roles, in plain English

Five is the number because it is the smallest number that covers the real cases. Fewer roles means you have to make compromises (the junior cannot do X without granting them too much else). More roles means nobody remembers what each one does.

**Owner.** The single person who owns the workspace. There is exactly one owner per workspace. The owner can do everything, including delete the workspace and transfer ownership. In a one-person business, this is you. In a multi-partner agency, it is whichever partner is the legal owner of the business.

**Admin.** Can do everything except delete the workspace or transfer ownership. Admins manage billing, manage members, create and delete projects, and configure integrations. Usually one to three people, typically the founders and the operations lead.

**Mod (Moderator).** Can do most day-to-day work but cannot manage billing or change member roles. Mods create projects, manage tasks and boards, moderate chat, and view invoices and the CRM. Creating and sending invoices and managing CRM records stay with Admins. This is the right role for senior staff and project managers, where you trust them with delivery but do not want them changing the company subscription or its finances.

**Member.** Can do their job. Members work on tasks, log time, comment, and chat, and can view the CRM and invoices for context. They cannot create projects, create or send invoices, or change CRM records. This is the right role for most of your team.

**Guest.** Least-privilege access for people outside your team. By default a guest can view files, folders, and events, and sees only the projects they are assigned to as the client. Access to a project's board or chat is granted per resource by an admin, so a guest never sees time entries, invoices, the CRM, or the rest of the workspace. This is the right role for clients you want to share project status with, and for short-term freelancers on a single project.

That is the entire model. Five roles. Each one solves a specific problem that the next one down cannot. Each one feels obvious in hindsight.

## Why five and not "as many as you need"

The temptation to add custom roles comes from a misdiagnosis. You think you have a permissions problem. You usually have an organizational problem.

If you find yourself wanting "Member but also can send invoices," ask why this person needs to bill clients. Usually the answer is one of:

- They are running billing and finance, in which case they should be an Admin
- They are a partner who happens not to do the daily work, in which case they should be an Admin
- They just need to read an invoice for a project they are on, in which case they already can as a Member

In every case, one of the five existing roles applies. The only legitimate reason to add a custom role is when you have a regulatory requirement (e.g. SOX-style separation of duties) and even then, you usually want the new role to be a *modifier* on Member, not a brand-new tier.

> If you are creating your sixth role, you do not have a roles problem. You have an org chart problem. Fix that first.

## Workspace role vs per-resource access

The five roles set the workspace baseline. Your internal team, Owner, Admin, Mod, and Member, can see every project in the workspace. That is deliberate: people on the team should not be blocked from context.

Scoping happens at the Guest tier. A guest sees only the projects they are assigned to as the client, plus any board, chat, or folder an admin grants them by name. This per-resource model is what lets you bring an external client or a single-project freelancer into the same workspace without exposing everything else.

So the lever is not "hide projects from teammates," it is "grant a guest exactly the resources they should see." You do not need a new role for "client who can see project A but not project B." You invite them as a guest, assign them to project A, and grant access to that project's board and chat. The role stays Guest; the per-resource grants are the lever.

## Granting and revoking, the right way

A few practical rules.

**Grant the lowest role that fits.** New hires start as Member by default. Promote to Mod when they take on project management responsibility. Promote to Admin when they need to manage other people. Never grant Admin on day one.

**Revoke immediately on offboarding.** When someone leaves the agency, remove them from the workspace the same day. Their old work stays attributed to them in history, but their access is gone.

**Audit quarterly.** Once a quarter, run through your member list. For each person, ask: is this role still right? Are they still active? People drift up the role ladder over time without anyone noticing.

**Use Guest aggressively.** If you find yourself adding a Member just to give them access to one project, downgrade them to Guest scoped to that project instead. Most "Member for one engagement" cases are actually Guest cases.

## What the team experiences

When the five-role system is set up well, this is what each role's daily experience looks like.

**Owner and Admins** see the full workspace. They are responsible for the platform and the business. They handle billing, ops, integrations, and people decisions.

**Mods** see every project and drive the day-to-day delivery. They manage tasks, boards, and chat, and keep client work moving. They do not handle billing, seat counts, or cutting invoices; that stays with admins.

**Members** see the workspace's projects and get to work: tasks, logged time, shipped work, and the relevant channels. They can look at the CRM and invoices for context, but creating projects and billing clients is not their job.

**Guests** see only the projects assigned to them, in a clean view. They follow status and download files, and where you have granted it, they comment and chat on that project. They cannot get lost in the rest of the workspace because the rest of the workspace is hidden from them.

Each role feels right because each role's user does not have to know the others exist. Nobody is fighting the system to do their job; nobody is accidentally seeing something they should not.

## When the five-role model is not enough

Honest disclosure: there are agencies where five is not enough. Large enterprise consultancies with regulated client industries (healthcare, finance, government) need more granular separation. Agencies running multi-tenant white-label platforms need different permissions still.

But these are not the cases most people are in. If your agency is between five and fifty people and you are still hitting role friction, the answer is almost always to restructure how you assign existing roles, not to invent new ones.

## Set this up before you need it

The best time to install the five-role model is when your workspace is empty. The second-best time is now, before your team grows past twenty. After twenty, the retrofit gets expensive in practice (lots of conversations, lots of double-checking that nobody lost access to something they need).

Start a workspace, set up the five roles as described, and invite your team in. You will save yourself a permissions-audit weekend in year two. Get started with a free workspace and have your role model wired in within the hour.