Deliverables

Deliverables at /items/deliverable tracks client-facing outputs: the artifacts the tenant owes, each with a status, an owner, and a due date. Internal steps toward them live at Tasks; the projects they roll into live at Projects; the full model lives on the Work items hub.

• Tabs split the list three ways: All Deliverable, Active Deliverables, Internal Review. Search, sort, columns, and filters narrow the rows; New Deliverable creates top-right.
• The table lists title, status, owner, due date, project, type, and effort per row.
• Completed rows with no owner are history without accountability — fine for the archive, a warning for anything active.

• A deliverable without a due date is a wish. A deliverable without an owner is two wishes. Set both before the work starts, not after it slips.
• Deliverables and Tasks are work items: their types, fields, and defaults live under Work Item Types, and their statuses run inside Settings Workflows. Move a row only when the work actually moved.
• Repeatable outputs start from Templates. If the same deliverable gets rebuilt every engagement, the template should exist.

What next

• Work items: the hub — hierarchy, lists, customization, workflows, approvals, sessions.
• Projects: the hierarchy deliverables roll into.
• Tasks: the internal steps behind each output.
• Templates: repeatable shapes for recurring outputs.
• Work Item Types: the types, fields, and defaults behind these rows.