monday.com

monday.com

monday.com is a work OS where teams run projects on boards with groups, items (rows), and column values (status, owners, dates, numbers).

First moves

1. Current user — confirm which monday.com account is connected.
2. Workspaces — discover workspace scope when the account spans multiple teams or clients.
3. Boards — list boards in a workspace to pick the board the user means.
4. Board schema — load column ids, types, and group layout before creating items or interpreting status columns.
5. Groups — read sprint buckets, stages, or swimlanes that partition items on a board.
6. Items — list board rows with pagination or open one item with all column values filled in.
7. Updates — read comment threads and replies on an item for standup or blocker context.
8. Subitems — list nested checklist rows and their column values under a parent item.
9. Users — member directory for interpreting people columns and assignment fields.

Data model

Workspace → board → group → item. Items carry column values keyed by column id. Subitems nest under parent items. Updates are the comment stream on an item.

Operational order

1. Resolve workspace and board before drilling into rows — do not guess board ids from titles alone.
2. Load board schema every time you create items, change column values, or interpret status labels.
3. List groups when the user names a stage ("In Progress", "Backlog") to get the correct group id.
4. Pull items with a reasonable page size; follow the cursor when the user asks for more rows.
5. Read updates on specific items when the question is about blockers, decisions, or handoff notes.

Writes

Create items in a named group, set column values by column id and type, post updates (comments), move items between groups, create boards and groups, and delete rows when the user explicitly requests cleanup. Column types differ — status, people, date, and mirror columns need schema-aware values.

Gotchas

• Board schema first — column ids and types come from the board layout; display titles alone are not reliable ids.
• Typed columns — status, person, mirror, and date columns return different shapes; read schema before writing.
• Pagination — item lists page with a cursor; advance the cursor instead of re-fetching the first page.
• Wide boards — requesting every column on a large board is slow; filter to the columns the user cares about.
• Subitems — checklist work lives on subitems; do not assume parent item columns cover nested tasks.
• Rate limits — prefer filtered item pulls over full-board dumps on busy accounts.