How to Structure a monday.com Workspace for Multi-Department Operations

Gwilym Pugh — Sun, 05 Apr 2026 14:43:00 +0000

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.

DEV Community: Gwilym Pugh