monday.com Work Management Advanced study materials
monday.com Work Management Advanced study resources

Subitems at the center of a delivery portfolio

monday.com Work Management Advanced · Put your knowledge to work in context.

All case studies

Subitems at the center of a delivery portfolio

A 45-person professional services firm runs 52 active client engagements on a single monday.com board. Each engagement is an item; each deliverable is a subitem, 6–12 per engagement, for roughly 450 subitems. Groups are arranged by region: North America, EMEA, APAC. The operations lead built an executive dashboard that counts items and charts item status, and a workload view intended to show each consultant’s open work. The dashboard reports 52 active engagements while the delivery board shows 450+ pieces of work, and the workload view shows almost no load for junior consultants who mainly own subitems. A CRM integration writes client health into a connect-boards column, but the mirrored health value on the engagement item is often a day stale. The firm wants client-level health, consultant capacity, and deliverable-level tracking without duplicating updates. The account is on Work Management Advanced with 60 seats and no dedicated developer.

1. Explain why the executive dashboard and workload view undercount the team’s actual work, and identify what part of the board structure is causing the mismatch.

Read the worked answer

The mismatch is structural, not a widget bug. The board counts engagements as top-level items; the 450 deliverables are subitems, which behave like a separate item type. Many dashboard widgets and workload views aggregate the parent item, and a people column on the parent does not see assignees on subitems. So the Numbers widget reports 52 engagements, and the workload view shows senior owners but not junior consultants. The mirror column is read-only and refreshes from the connected CRM item; a blank or stale value usually means the connection is missing, the source item was archived or deleted, the viewer lacks permission to the CRM board, or the mirror has not refreshed. Before rebuilding, I would compare the dashboard filter, the board’s archived state, and the widget’s source setting with the board’s item count, then check whether each widget supports subitems. This tells us whether the fix is filter and source configuration or a data-model change.

2. Recommend a target item hierarchy that supports engagement-level health, deliverable tracking, and consultant capacity, and state the trade-offs.

Read the worked answer

Target a two-board model. Keep an Engagements board with one item per client engagement for health, contract value, and owner. Move deliverables to a Deliverables board with one item per deliverable, a People column for the consultant, a Status column, and a Connect Boards column linking to the engagement. Roll up progress to the engagement with a mirror or rollup, or with an automation that recalculates health when deliverable status changes. Use subitems only for checklist steps inside a deliverable, not for work you must report across engagements. Trade-offs: the separate board adds a connection to maintain and requires users to work in two places, but it gives reliable capacity reporting, cross-engagement filtering, and one source of truth. Keeping subitems is cheaper but requires subitem-aware widgets, does not roll up natively, and makes client-level health harder to automate. Because the firm needs both capacity and client health, the separate board is the better long-term structure.

3. The CRM health mirror is stale and sometimes blank. What would you check and change, and how would you prevent duplicate client records?

Read the worked answer

First verify the connection, not the mirror. I would check whether every engagement item has a value in the Connect Boards column, whether the linked CRM item still exists and is active, whether the dashboard viewer can view the CRM board, and whether the mirror is blank versus stale. Mirrors are read-only and depend on the source; they will not fix duplicate clients. To prevent duplicates, use a stable client ID in the CRM and in the engagement item name or a text column, and automate the connection from the CRM ID rather than matching on free-text client name. If writeback to the CRM is required, use an automation or integration and document which system is authoritative; a mirror alone cannot update the CRM. I would also add a weekly check for unlinked engagements and treat a blank mirror as a data-quality exception, not a dashboard issue.