monday.com Work Management Advanced common mistakes
monday.com Work Management Advanced · Understand the traps and how to avoid them.
Reaching for subitems as the default way to model any related work - for example putting every client's deliverables as subitems under a single 'Clients' item and assuming they will roll up into dashboard widgets, board filters and automations exactly like top-level items.
Subitems sit on a separate, parallel structure. On most plans they are a single level and cannot be given their own subitems; they are excluded from many board-level filters, item counts and widget aggregations, and they cannot be re-parented to a different item. Candidates design a tree, then discover the reporting they promised cannot be built, and misdiagnose it as a widget bug.
What to do instead
Reserve subitems for checklist-style breakdown owned by one person on one item. When another team owns the work, reports on it, or needs it as a first-class row, create a second board and link it with Connect Boards plus a Mirror column, then aggregate on a portfolio board. For deeper hierarchies, chain connected boards rather than nesting.
Modelling workflow state with groups ('To Do', 'In Progress', 'Done') and moving items between groups, while the automations and status charts on the same board are built against a Status column.
Groups are structural containers, not data. Moving an item between groups is not a status change, so 'when status changes to Done' recipes never fire and status-based charts show empty buckets. Candidates then add a second, parallel status column, and the board ends up with two competing sources of truth.
What to do instead
Put state in a Status (or dropdown) column and key automations off it. Use groups for stable lanes - team, region, phase, client - and use 'when item is moved to group' only when the group move genuinely is the event you care about. If you inherit a group-as-status board, migrate state into a status column before building dashboards.
Building one large board with a group per client or per team and dozens of status columns because it feels simpler than maintaining several boards.
Board permissions, automations, saved views and dashboard filters are all board-scoped. A single board forces every viewer to see every client's data, makes column permissions mandatory to compensate, and degrades as item and column counts grow. Candidates who model this way cannot answer the permission and scaling scenarios correctly because the structure makes the right answer impossible.
What to do instead
Use one board per repeating entity, generated from a standardised template, and link each to a portfolio board with Connect Boards. Split boards per team so workspace membership and board-level permissions can be scoped. Keep column names and types identical across the template so dashboards built on the portfolio board keep working.
Writing an automation such as 'when Status changes to Done, set Status to Archived', or two recipes that each write the other's status, with no guard condition.
Every write is itself a status change, so the recipe re-triggers itself or its sibling. The visible result ranges from duplicated notifications and owner emails to an automation that monday disables after repeated runs. Candidates read the symptom as a broken integration or a permissions problem rather than a loop they authored.
What to do instead
Add 'and only if' conditions, or keep the state machine in a separate column or board that nothing writes back to. For archiving, prefer 'when status changes to Done, move item to group' over writing the same column. Enable one item at a time and watch the automation activity log before turning the recipe on for the whole board.
Designing 'every day at 9am, check every item and notify the owner' style recipes, plus one recipe per group, and assuming the plan's automation allowance is effectively unlimited.
Actions are consumed per item per run, so time-based and date-based recipes multiply by item count, and duplicating boards multiplies consumption again. The workflow passes in a ten-item test board and silently stops mid-month in production. Candidates then blame the recipe instead of the quota model.
What to do instead
Prefer event-driven triggers - status changed, date arrived, item created - over polling. Consolidate with 'and only if' conditions instead of one recipe per group, and move bulk logic to a single scheduled recipe on a summary board. Check the account's action usage before rollout and after each template deployment.
Assuming a Slack, Teams, email or calendar integration syncs both ways in real time, and building the process on the assumption that whoever set the integration up will stay on the team forever.
Most native integrations are one-directional notifications or single triggers; true two-way record sync needs a connector app. Integrations also authenticate as the user who connected them, so deactivating or removing that person silently breaks the flow while the board still looks healthy. Candidates misread the silent failure as a monday outage.
What to do instead
Check direction and trigger type in the integration's own description before designing the process. Connect integrations through a role or service account rather than a named individual, record an owner for each integration, and verify behaviour using the automation/integration activity log rather than assuming success.
Sharing a dashboard with a stakeholder and assuming they now see the same numbers, filters and totals the builder sees.
A dashboard is a view layer with no data access of its own. Each viewer only sees data from boards and folders they are permitted to open, so widgets render partial results, empty states or access warnings. Candidates interpret this as a broken widget or a misconfigured filter and keep rebuilding the dashboard instead of fixing entitlements.
What to do instead
Grant board or workspace access, or a guest seat scoped to the specific boards, before sharing the dashboard. Preview the dashboard as a viewer with a test account. For external stakeholders, build a dedicated summary board, share only that, and put the roll-up widgets on a dashboard backed by it.
Reading a chart as 'sum of the numbers column' when the widget is actually counting items, or treating Group By and Stack By as interchangeable when laying out a breakdown.
The Charts widget counts items by default; summing or averaging a numbers column is a separate aggregation choice that must be set explicitly. Group By creates the primary series, Stack By splits within it, and status labels with zero items are simply absent from the chart, so 'missing' categories are usually empty ones rather than a data loss.
What to do instead
State the aggregation out loud and match it to the question - count of items versus sum or average of a numbers column. Use Group By for the primary dimension and Stack By for a second. Cross-check any headline number against a Table widget with the same filters before presenting it.
Treating account admin, workspace admin, board owner and editor/subscriber as roughly equivalent - for example making someone a workspace admin so they can edit one board, or leaving a board owner off a board that feeds an automated dashboard.
monday stacks three permission layers: account role, workspace role and board-level permissions, with column permissions and item-level editing added on Enterprise plans. Over-granting at the workspace layer opens every board in that workspace; under-granting at board level blocks the person who maintains the automations or the dashboard. Candidates answer with the layer they happen to use daily.
What to do instead
Grant the narrowest layer that satisfies the need: board-level edit for a single board, workspace membership for discovery, account admin reserved for governance. Map who owns each board, its automations and its dashboards, then review the matrix when people change teams or leave.
Rolling work management out to new teams by duplicating a mature board or reinstalling a template repeatedly, without auditing what travels with the copy.
Duplication copies automations, integrations and saved views along with structure. A template with a dozen recipes installed across twenty teams silently adds hundreds of recipes to the quota, and any hard-coded email or chat integration now fires from every copy. Candidates then cannot explain a usage spike or a wave of duplicate owner notifications.
What to do instead
Maintain a template board containing only generic, shared automations and no board-specific integrations. Duplicate the stripped template, then add per-board recipes and integrations deliberately. Keep a register of automations per board and review action usage after each rollout wave.