Draft — in editorial review, not yet published. Content has not been approved by a human reviewer.
Lesson 21 / 50 · Version 2.2.0
monday.com Boards and Workflows
- Level
- Beginner
- Duration
- 15 min learn + 15 min apply
- Prerequisites:
- None
Why it matters: A board is only as good as the process behind it. Teams that start with "what is one item?" get clear ownership and honest status; teams that start with columns get a colorful spreadsheet no one trusts.
By the end you can:
- Define what one board item represents
- Choose a small, purposeful set of columns and statuses
- Use views and Connect Boards appropriately
- Add one automation without losing process ownership
Learn (15 min)
1. Model the process (5 min)
A board tracks items; each item is one unit of work (a client request, a campaign, a shoot). Write the definition first: "One item = one client request, from first inquiry to delivered files." Also define when an item is done. Group items by stage or time; use sub-items only for true sub-steps.
2. Columns and views (5 min)
Start with 5–8 columns that each support a decision.
| Column | Type | Purpose |
|---|---|---|
| Owner | People | Who acts next |
| Status | Status | Where it is (3–6 meaningful values) |
| Due date | Date | When action is due |
| Service | Dropdown | Routing/reporting |
| Value | Numbers | Forecasting |
| Good statuses describe states someone acts on: New → Quoted → Booked → Delivered → Closed. Views (table, Kanban, timeline, calendar) change presentation, not the data model; a bad workflow stays bad in any view. |
3. Connect and automate (5 min)
Connect Boards links related items across boards (a client item to its project items). Automations follow "when this, then that" recipes (when status changes to Booked, notify the owner; when the due date arrives, remind the owner). Check column-type support and your plan before designing around a feature. Assign someone to handle exceptions and stale items.
Apply (15 min)
Worked example (3 min). Client Requests board. Item = one request. Columns: Owner, Status (New/Quoted/Booked/Delivered/Closed), Due, Service, Value. Automation: when Status = Quoted and no update for 3 days → notify Owner. Rule for orphan items: if no owner, a weekly view "No owner" is reviewed by the ops lead.
Lab (7 min): Design a board.
- Write the item definition and the "done" definition.
- List six columns with types and a purpose for each.
- Write three status values and what triggers each change.
- Create one view for staff and one for a manager.
- Write one automation and the case it won't cover.
Deliverable: A one-page board spec. You're done when: Every column answers a question someone really asks.
Check yourself (5 min)
- What should one item represent?
- Why limit statuses?
- Do views create new data?
- Scenario: An automation notifies owners, but 20% of items have no owner. What's the real fix?
- What are Connect Boards for?
Reference
Common mistakes
| Symptom | Likely cause | Fix |
|---|---|---|
| Nobody trusts statuses | Too many/ambiguous labels | Fewer, action-based statuses |
| Items pile up | No owner/exception process | Owner rule + weekly review view |
| Feature unavailable | Plan/column-type limits | Check entitlements first |
Cheat sheet: Define item → choose fields → set status flow → useful views → small testable automation → named exception owner.
Key terms: board, item, column, view, automation, Connect Boards.
Interview prompts: How do you design a board for a service business? When do you split into multiple boards?
Go deeper: monday.com structural hierarchy · Column basics · Automations
Next: Lesson 22 — the monday.com API.