AI & Business Process consulting.
monday.com Platinum Partner.
If you’ve ever opened monday.com’s Administration section looking for a simple answer to “can this person see that board,” you’ve probably found four different permission layers, a handful of user types, and no clear place to start. That’s not you missing something. The platform genuinely stacks permissions in layers, and most of the confusion people run into comes from not knowing which layer they’re actually looking at.
Here’s the short version before we get into it: monday.com controls access at four levels, account, workspace, board, and column. Each layer can only restrict what the layer above it already allows, never expand it. Once that clicks, most permission questions answer themselves.
The four user types
Every person on your account is one of four types.
Admins manage the account itself, billing, security, user management, the works. You can have more than one, and most accounts should, so you’re not stuck if one admin is unavailable or leaves.
Members are your core team. They can access shared boards, create content, and collaborate normally. This is the default for anyone doing real work in the platform.
Viewers can see boards they’ve been invited to, but can’t edit anything. They’re free, don’t count toward your seat count, and are worth using more often than most accounts do, stakeholders who just need visibility don’t need a paid seat.
Guests are external people, clients, contractors, vendors, who only see boards they’ve been explicitly invited to. They never see your account structure beyond that.
That’s the full list. Everything else, teams, departments, custom roles, is a way of organising and fine-tuning within those four types, not a fifth category.
Why permissions feel more complicated than that
Because there are four separate layers where access gets decided, and they interact.
Account permissions are the account-wide rules, set by admins, that decide what each user type can do across the whole account. Can members create workspaces? Export data? Invite guests? This is the ceiling. Nothing below this layer can grant more than what’s allowed here.
Workspace permissions control what happens inside a specific workspace, who can create boards in it, who can join it. But a workspace can never grant more access than the account allows. If admins have switched off workspace creation for members at the account level, no workspace setting can override that.
Board permissions decide who can view or edit a specific board’s content and structure. This is usually where people go first, because it’s the most visible, but it’s actually the third layer down.
Column permissions are the finest-grained control, restricting who can see or edit a single column, useful for salary data, margins, anything sensitive sitting inside an otherwise shared board.
The practical implication: if something isn’t working the way you expect at the board level, check the workspace and account levels above it before you assume the board setting is broken. Nine times out of ten, it’s a higher layer quietly overriding what you’re trying to do lower down.
Three situations, sorted
A new employee joins your team.
Make them a Member. Add them to the relevant team(s) so they inherit access to the boards those teams use. Don’t create a one-off custom permission set for them unless their role is genuinely unusual, it’s extra maintenance for no real benefit.
An external contractor needs to see one project.
Make them a Guest, and invite them directly to the one board or shareable board they need. Guests never see anything outside what they’re explicitly invited to, so this is the cleanest way to give access without exposing the rest of your account.
A department head needs oversight without full admin rights.
This is where it’s worth pausing before reaching for “just make them an admin,” which is the most common overcorrection we see. Full admin access hands over billing, security settings, and every other user’s data, usually far more than the actual need. On the Enterprise plan, custom roles let you build a role that has, say, user management rights for their department only, without touching anything else. On other plans, workspace ownership for their specific workspace is usually enough.
Where this gets genuinely complicated
Custom roles, department-scoped admin rights, and provisioning across multiple tools are real capabilities, but they’re also where a wrong setting can lock people out of work they need, or leave a sensitive board more open than intended. If you’re mapping permissions to an actual org chart with more than a couple of exception cases, that’s less a five-minute settings change and more a structural decision worth getting right the first time. That’s the kind of thing we help clients think through properly, rather than bolting on custom roles reactively every time someone new joins.