A monday.com account scales when its structure follows how your business is organised rather than how each team improvises. That means workspaces mapped to functions or business units, a deliberate decision about whether each board represents a process or a project, groups and columns used for what each is genuinely good at, connected boards instead of duplicated ones, and standards enforced through admin settings and managed columns rather than left to discipline. Most accounts that become unmanageable did so through board sprawl, where a new board gets created every time something new comes up, and nobody ever removes one.
Why accounts stop scaling
Almost every monday account that becomes a problem got there the same way. It started clean, someone needed to track something new, they made a board, that worked, so it happened again. Two years later there are four hundred boards, several tracking the same thing differently, and nobody’s certain which are still in use. Nothing went wrong at any single step. The absence was structural: no decision about what a board is for, so a board became the answer to everything.
The rules that matter most
Process boards or project boards? Decide deliberately
The first structural decision is what a board actually represents, and there’s no universal answer. Both patterns are correct in the right circumstances, and the failure comes from drifting into one without deciding.
A board per process works when you’re running the same sequence many times: client onboarding, recruitment, service requests, job tracking, applications. Each instance becomes an item moving through stages. You get visibility across every instance at once, structure that’s consistent by default, and reporting that works without effort.
A board per project works when a project has enough internal complexity to justify its own structure: dozens of distinct tasks with their own owners, dates and dependencies. Compressing that onto a single item loses the detail you actually need to manage it.
At enterprise scale, board-per-project is frequently the right structure, and monday’s portfolio capabilities are built for exactly that shape. Projects run as their own boards, managed templates keep them structurally consistent, and a portfolio layer rolls them up so leadership still sees across the whole programme. Resourcing and capacity planning sit above that.
That combination is what makes per-project work. The structure holds because templates enforce consistency and the portfolio provides the cross-project view that a single board would otherwise have given you.
The actual mistake isn’t project boards. It’s a board per client for what is really a repeatable process, or a board per project with no templates and no portfolio above it, so every one is built slightly differently and nobody can see across them. That’s where sprawl comes from, and it’s the pattern worth avoiding.
The test: does this thing have genuine internal complexity that needs its own structure, or is it one instance of something you do repeatedly? If it’s the latter, it’s an item. If it’s the former, give it a board and make sure templates and a portfolio are in place to hold it together.
Groups, columns, and knowing what each is for
Group structure is flexible, and it should follow your workflow rather than a rule. That said, there’s a distinction worth understanding, because getting it wrong is a common cause of a board that can’t show you anything useful.
Groups are most powerful representing something that changes. Stages are the classic case: items move between groups as work progresses, so the board is readable at a glance and movement itself becomes the status update. Where your workflow has a natural sequence, that’s usually the strongest use of groups.
Columns are better for attributes that describe an item rather than track its progress: client, type, owner, priority, region. The advantage is that columns can be grouped, filtered and viewed dynamically, so the same board can be sliced by client for one person and by owner for another, without either arrangement being locked in.
The problem to avoid is putting a static attribute into groups on a board where you also need to see progress. If groups are permanently set by client or by type, items never move, and the board loses its ability to show you state. Where that attribute lives in a column instead, you keep both: progress in the groups, and every other cut available on demand through views.
Where your workflow genuinely has no sequence, grouping by attribute may be exactly right. The point is to make it a decision rather than a default.
Connect boards, don’t duplicate them
When boards need to share information, connect them with a connected boards column and mirror what you need. Copying data between boards guarantees drift, and reconciling drifted data becomes somebody’s recurring job. The principle: each piece of information should live in exactly one place, and everywhere else should reference it.
Workspaces reflect the business, not individuals
Workspaces are the top level, so they should map to something stable: functions, departments or business units. Structuring them around individual people creates the same problem as a board per client, because when someone leaves or changes role, the structure no longer describes anything real.
Set standards, then enforce them in the platform
Unglamorous and disproportionately valuable. Agree how boards, groups, columns and items are named, and what the standard set of columns looks like for common board types.
Without that you get “Client Onboarding”, “client onboarding v2”, “Onboarding, New” and “NEW CLIENT PROCESS”, all live, none obviously canonical. Search stops working, people build duplicates because they can’t find the original, and the account becomes navigable only by the people who built it.
The part most accounts miss is that you don’t have to rely on people remembering. monday gives you enforcement mechanisms at the account level: default settings in admin, and managed columns that let you define a column centrally and reuse it consistently across boards. That turns a convention people are supposed to follow into a standard the platform applies.
Use them. Conventions held by discipline decay the moment the person holding them gets busy. Conventions held by the platform don’t.
Structure for the reporting you’ll need
Dashboards can pull from multiple boards and will let you match columns across them, so a small amount of inconsistency isn’t fatal. But the more standardised your boards are, the less work reporting becomes and the more reliable it stays as things change.
Where it genuinely bites is when the same concept is held in different shapes: status in a column on one board and in a group on another, or a date stored as text here and as a date column there. Matching around that is possible, but it’s fragile, and it breaks quietly when someone restructures a board.
Decide early what leadership will want to see, and make sure the boards feeding a shared dashboard use the same shapes for the same concepts. Managed columns are the practical way to hold that.
The mistakes that cause the most damage
Board sprawl. Covered above, and the most common by far. Usually a board per client for a repeatable process, or project boards created ad hoc with no templates or portfolio holding them together.
Everything on one board. The opposite failure. A single enormous board holding several unrelated processes, with dozens of columns most of which are irrelevant to most items. Usually a reaction to previous sprawl.
Columns for everything. Every question that ever gets asked becomes a column. Boards end up thirty columns wide, most empty most of the time. If a column is populated on a small minority of items, it probably belongs somewhere else.
Automations built before the process is settled. Automations encode assumptions. Built too early, they encode the wrong ones and then have to be found and unpicked, usually by someone who didn’t build them.
No archiving discipline. Completed work staying live forever makes everything slower to load and harder to search. Archiving should be part of the process, not an occasional cleanup.
No owner. Someone needs to own the account’s structure, approving new boards and holding conventions. Without that role, entropy always wins, because creating a board is easier than finding the right one.
Governance, lightly
Not bureaucracy. Three things, done consistently:
Someone owns the structure. New boards go through them. Usually two minutes, and it prevents most sprawl.
A quarterly review. What’s unused, what’s duplicated, what’s drifted from convention. Half an hour, four times a year.
Templates for repeated things. If a new client or project needs a consistent setup, template it. It stops each new instance being slightly different and makes structure the default rather than an effort.
If your account is already a mess
Most are, and it’s recoverable.
Start by finding what’s actually used. Boards with no activity in months are candidates for archiving, and archiving is reversible.
Then find the duplicates, the same process tracked in multiple places, and decide which is canonical. Consolidating those usually removes a surprising proportion of the clutter.
Then restructure the highest-traffic process properly rather than attempting the whole account. One process restructured well demonstrates the value and gives you a pattern to apply.
And put conventions in place before rebuilding, so you’re not recreating the same problem more neatly.