When your company hits 30-50 people across three or more departments, your monday.com instance stops being a collection of boards and starts being an architectural decision. How you structure workspaces, boards, and permissions at this stage determines whether the platform scales with you or becomes another tool people work around.
I've set up monday.com for companies across construction, recruitment, financial services, and healthcare. The pattern is consistent: teams that think about workspace architecture early save themselves a painful restructuring 6-12 months later. Teams that don't end up with 200 boards scattered across one workspace, no naming conventions, and permissions that either lock everyone out or let everyone see everything.
Here's what I've learned about structuring workspaces for multi-department operations.
The Single-Workspace Trap
Most companies start with one workspace. Marketing has their boards, Sales has theirs, Operations has theirs. It works until it doesn't.
The breaking point usually comes from one of three places:
Permission sprawl. Your HR team has a board tracking employee reviews. It's in the same workspace as the marketing content calendar. Everyone can see both. You can set board-level permissions, but with 40 boards in one workspace, managing individual board permissions becomes a full-time job.
Information overload. When someone opens monday.com, they see every board in the workspace. A salesperson doesn't need to see the engineering sprint board. A recruiter doesn't need to see the finance reporting dashboard. But they're all there, cluttering the sidebar.
Naming collision. Marketing has a "Tasks" board. Operations has a "Tasks" board. Engineering has a "Tasks" board. Search becomes useless.
The Multi-Workspace Model
The fix is straightforward: one workspace per department or functional area. A typical structure for a 40-person company:
Company Account
βββ Sales & CRM (workspace)
β βββ Deals Pipeline
β βββ Contacts
β βββ Accounts
β βββ Sales Reports Dashboard
βββ Operations (workspace)
β βββ Project Delivery
β βββ Resource Planning
β βββ Client Onboarding
β βββ Ops Dashboard
βββ Marketing (workspace)
β βββ Content Calendar
β βββ Campaign Tracker
β βββ SEO Pipeline
β βββ Marketing Dashboard
βββ HR & Admin (workspace)
β βββ Recruitment Pipeline
β βββ Employee Directory
β βββ Leave Tracker
β βββ Onboarding Checklist
βββ Company-Wide (workspace)
βββ All-Hands Meeting Notes
βββ OKRs / Goals
βββ IT Requests
βββ Cross-Department Projects
Each workspace has its own membership. Sales team members are added to the Sales workspace. They can see everything in Sales, nothing in HR. If someone needs cross-department visibility (like a COO), they're added to multiple workspaces.
The Cross-Department Problem
Separate workspaces solve the permission and clutter problems. They create a new one: how do departments share data?
A sales deal that closes needs to trigger an operations onboarding workflow. A marketing campaign needs to reference the sales pipeline to calculate ROI. A new hire in HR needs to appear on the IT equipment provisioning board.
Monday.com solves this with connected boards and mirror columns. Here's how they work in practice:
Connected Boards
A board relation column lets you link items on one board to items on another board, even across workspaces. Your Deals board in the Sales workspace can have a column that connects each deal to a Project on the Operations board.
When a salesperson closes a deal, they link it to the corresponding project. Operations can now see which deal originated the project. Sales can see the project delivery status without leaving their workspace.
Mirror Columns
Once boards are connected, mirror columns let you pull specific data from the connected board into your current view. Operations doesn't need to open the Sales workspace to see the deal value or client contact. They create a mirror column that reflects that data from the Deals board.
The data stays in one place (the Deals board owns the deal value). The mirror just displays it. If Sales updates the deal value, the mirror updates automatically.
The Practical Pattern
For a typical sales-to-operations handoff:
- Sales workspace has a Deals board with a "Connected Project" column (board relation to Operations > Project Delivery)
- Operations workspace has Project Delivery board with mirror columns pulling Deal Value, Client Contact, and Close Date from the connected deal
- An automation fires when Deal Status changes to "Won": create an item on Project Delivery, link it to the deal, notify the operations lead
The same pattern works for any cross-department workflow: marketing-to-sales lead handoff, HR-to-IT equipment provisioning, client onboarding across sales and operations.
Naming Conventions That Scale
This sounds mundane until you have 80 boards and can't find anything. Establish conventions early:
Boards: [Department] - [Purpose] or [Department] - [Entity Type]
- Sales - Deals Pipeline
- Ops - Project Delivery
- HR - Recruitment Pipeline
Groups within boards: Use consistent status-based names
- New / Incoming
- In Progress / Active
- Review / Approval
- Done / Archived
Views: Name views by audience or purpose
- "My Tasks" (filtered to current user)
- "This Week" (filtered by date)
- "Client: [Name]" (filtered by client)
- "Manager Overview" (summary/dashboard view)
Permission Architecture
Monday.com has three permission levels that matter for workspace design:
Workspace membership:
- Members can see and edit all boards in the workspace
- Viewers can see but not edit
Board-level permissions:
- Editable by everyone in the workspace
- Editable by board owner only (others can view)
- Private (only invited members)
Column-level permissions (Enterprise plan):
- Restrict who can edit specific columns
The practical setup for most companies:
| Role | Workspaces | Permission |
|---|---|---|
| Department staff | Own department + Company-Wide | Member |
| Department manager | Own department + any they oversee | Member |
| C-suite / leadership | All workspaces | Member or Viewer |
| External contractors | Specific boards only (via guest access) | Guest |
Key principle: Default to workspace-level membership for simplicity. Only use board-level restrictions for genuinely sensitive boards (compensation data, performance reviews, legal matters).
Automations Across Workspaces
Cross-workspace automations are where the real operational value lives. The three most valuable patterns:
1. Status-triggered item creation
"When a deal moves to Won in Sales, create a project in Operations."
This eliminates the manual handoff where someone in Sales emails Operations to say "we closed the deal, can you set up the project?" The project appears automatically with all relevant deal data mirrored.
2. Date-based notifications
"When a project delivery date is 7 days away, notify the account manager in Sales."
This keeps Sales informed about delivery timelines without requiring Operations to send manual updates. The account manager can proactively reach out to the client before delivery, not after.
3. Status-based dashboard updates
"When a project status changes to Complete, update the client health score on the Accounts board."
This creates a feedback loop between delivery and relationship management. If every project is delivered on time, the account health reflects that. If projects are consistently late, Sales sees the impact on client relationships.
Common Mistakes
After setting up workspaces for dozens of companies, these are the patterns I see teams get wrong:
Too many workspaces. One team created a separate workspace for every client project. With 30 active clients, the workspace list became unmanageable. Rule of thumb: workspaces map to departments or functions, not to individual projects or clients.
Too few boards in a workspace. The opposite problem: cramming everything into three mega-boards with 50 groups each. If a board has more than 10-12 groups, it probably needs to be split into separate boards.
No Company-Wide workspace. Cross-departmental initiatives (OKRs, all-hands action items, IT requests) need a shared space. Without it, these items end up scattered across department workspaces or worse, in email.
Automations without ownership. Someone builds 30 automations connecting Sales to Operations. That person leaves. Nobody knows which automations exist or what they do. Document every automation with a name, description, and owner. Keep a simple registry board: Automation Name, Trigger, Action, Owner, Last Updated.
Getting Started
If you're restructuring an existing monday.com instance:
Audit what exists. List every board, who uses it, and which department it belongs to. You'll probably find boards nobody uses and boards that should be merged.
Design workspaces on paper first. Map departments to workspaces. Identify cross-department data flows. Decide which boards need connected columns.
Migrate one department at a time. Move their boards to a new workspace, set up permissions, and let them run for a week before moving the next department.
Build cross-workspace connections last. Get each workspace stable before adding the complexity of connected boards and automations.
For a detailed walkthrough of workspace setup including permissions and governance, I've written a workspace structure tutorial that covers the full process.
The workspace architecture you choose today will either make monday.com feel like a unified operating system for your company, or like a slightly fancier collection of spreadsheets. The difference is 2-3 days of thoughtful planning upfront.
United States
NORTH AMERICA
Related News
How do you actually manage your content's SEO performance?
18h ago
America's CIA Recruited Iran's Nuclear Scientists - By Threatening To Kill Them
18h ago
Why NodeDB Might Be a Better Multi-Model Database
18h ago

Qodo AI Review 2026: Is It the Best AI Testing Tool?
18h ago

I built a local-first Obsidian suite to safely feed my vault to AI π οΈπ
19h ago