AI & Business Process consulting.
monday.com Platinum Partner.
Most monday.com accounts aren’t badly managed. They’re badly structured. The distinction matters because it changes what you actually do about it.
Management problems are about habits: boards not being archived, ownership not being assigned, naming going sideways over time. Structure problems are different. They’re about the bones of the account: how workspaces are set up, how boards relate to each other, whether the architecture reflects how the organisation actually works or how it worked two years ago when someone was figuring things out on the fly.
Both types cause pain, but structure problems cause more of it, and a clean-up routine won’t fix them. You can archive every orphaned board in an account and still have a workspace architecture that fights every new hire who tries to find anything.
The three-layer model most accounts need
monday.com gives you four structural elements to work with: workspaces, folders, boards, and items. The relationship between the first three is where most accounts go wrong.
Workspaces are the top-level containers. They should map to your major organisational units: departments, business functions, or significant ongoing programs, not to individual projects, teams within a team, or time periods. One workspace per department or major function is the pattern that holds as accounts grow. One workspace per project does not.
Folders sit inside workspaces. They’re useful for organising boards within a workspace into logical categories: current projects, operational boards that run continuously, templates, and an archive section for completed work that isn’t ready to be fully archived yet. Most workspaces need between two and four folders. More than that is usually a sign the workspace is doing too many jobs.
Boards live inside folders. They should be purpose-specific and named clearly enough that someone who didn’t create them knows what’s in them from the name alone.
The naming problem nobody fixes until it’s a crisis
A naming convention sounds like admin work. It is admin work, in the same way that folder structure on a shared drive is admin work: invisible when it’s right, a genuine productivity tax when it isn’t.
The basics that survive contact with a growing team:
- Board names should describe content, not purpose: “2025 Enterprise Client Projects” rather than “Client Tracker”
- Include the year or quarter in any board that’s time-bound
- Never use “Copy of” or “New” in a live board name. These are temporary names that become permanent
- Templates should be stored in a Templates folder and named with a prefix: “TEMPLATE: Project Kickoff”
Enforce this at the point of creation, not after the fact. An admin who reviews new boards weekly and renames the problematic ones early creates far less work than an admin who waits six months for a naming audit.
Open workspaces vs closed workspaces: a decision that matters more than most accounts realise
Every workspace in monday.com is either open or closed. Open workspaces are visible and joinable by any team member. Closed workspaces are invite-only.
Most accounts start with everything open because it’s simpler. As headcount and sensitivity of information grow, that default becomes a governance risk. Finance boards in an open workspace are visible to every member. HR processes in an open workspace are visible to every member. The solution isn’t to lock down everything, but to be deliberate about which workspaces should be closed from the start.
A reasonable default: operational and project workspaces that the whole organisation can see are open. Workspaces for finance, HR, executive planning, or anything with sensitive data are closed.
Board types and when to use which
Every board in monday.com is one of three types: Main, Private, or Shareable. These aren’t interchangeable, and picking the wrong one creates permission headaches that are annoying to unwind.
Main boards are visible to all members in the workspace. Available on all plans. Use these for anything the team genuinely needs shared visibility on: active projects, operational trackers, shared resources.
Private boards are only visible to the people explicitly invited. Available on Pro and Enterprise plans only. Use these for anything sensitive: performance reviews, budget boards, early-stage planning that isn’t ready to be shared. Critically, guests can’t be invited to private boards. Private is internal-only by design.
Shareable boards are for external collaboration. Available on Standard and above. They work like private boards in terms of visibility, with one key difference: guests (external people) can be invited. Use these for client-facing work, contractor access, or anything that needs to cross your organisation’s boundary.
The connection and mirror column question
Connect board and mirror columns are where account structure gets genuinely complex, and where a bad architectural decision early creates real problems at scale.
The short version: connect board columns link items across boards. Mirror columns pull data from a connected board into your current view. Together, they’re powerful for creating a single source of truth across related boards.
The practical caution: mirror what you actually need to see, not everything you could theoretically surface. Mirroring too many columns across too many boards slows performance and creates maintenance overhead every time an upstream board changes. The question to ask before adding a mirror column is whether you genuinely need that data visible in this board, or whether it’s enough to click through to the connected item when you need it.
Templates: underused in almost every account we see
Templates are one of the highest-leverage, lowest-maintenance investments an account admin can make. A well-built template board means every new project starts from the right structure rather than from a duplicate of whatever was closest to hand.
Keep templates in a dedicated Templates folder within each workspace. Review them every six months or when your process changes. A template that’s six months out of date is still better than no template, but a template that actively reflects how your team works is what actually gets used consistently.
When structure becomes a proper project
The patterns above handle most accounts in a stable growth phase. They don’t cover accounts that have grown significantly faster than their structure, accounts being inherited after a key person leaves, or organisations going through a restructure that changes how teams relate to each other.
In those cases, the right move is to map how the organisation actually works now, not how it worked when the account was set up, and build the architecture from that rather than patching the existing structure. That’s a proper scoping exercise, not a settings change.