Work items

Every tracked row on the Projects side is a work item: a typed record with an owner, a status, and a place in the hierarchy. Programs hold projects, projects hold deliverables, deliverables hold tasks. The lists, the types, the workflows, and the approvals below all hang off that one model.

The hierarchy

Program → project → deliverable → task, top to bottom. A program is the engagement container; a project is one bounded piece of work inside it; a deliverable is a client-facing output the tenant owes; a task is an internal step toward that output. Plan Brief and Deliverable Brief types exist but ship off — sessions cannot attach them until an admin turns them on under Work Item Types.

• Programs: the engagement containers at the top of the hierarchy.
• Projects: one bounded piece of work per row, each under a company.
• Deliverables: the client-facing outputs, each with owner and due date.
• Tasks: the shared list of internal steps; My Tasks is the personal slice.

One row means one thing. A project holding three engagements forces every view and mapping to guess; a deliverable without an owner is two wishes. Shared facts belong in mapped fields under Field Mappings, not in per-row improvisation.

The lists

Each type has its own list at /items/{typeKey}: /items/program, /items/project, /items/deliverable, /items/task. Tabs, search, sort, columns, and filters narrow the rows on each list; views shape them, and the org default for the views the team opens daily is set under Table Views.

Projects live at /items/project: one bounded piece of work per row, each under a company.

Deliverables live at /items/deliverable: the client-facing outputs, each with owner and due date.

Tasks live at /items/task: the shared list of internal steps.

Selecting a row opens its detail pane: description, subitems, files, and approvals beside the activity rail.

Subitems are the rows nested under the open record — the deliverables under a project, the tasks under a deliverable.

Customization

Work-item shape is configuration, not improvisation. Work Item Types holds the Types, Fields, and Defaults tabs: which types exist and are on, which fields appear on each type, and what new rows start with. Reference fields between types are assigned from each type’s Relationships tab; reusable field definitions live under Custom Fields.

Change types, fields, and defaults only when the owning process changed — sessions in flight reference them.

Repeatable shapes belong in Templates instead of rebuilt rows: programs, projects, deliverables, and tasks each have template kinds.

My Tasks at /my-tasks is the personal slice of the same model: the rows assigned to you with due dates and statuses, pinned in the sidebar quick links.

Workflows

Statuses move inside workflows. Each work-item type runs on a workflow; the workflow’s statuses are the only states a row can hold, and moving a row means the work actually moved — status theater confuses everyone downstream. Transition rules, where on, decide whether the workflow enforces its transitions or leaves them advisory.

Approvals

Work items flow through Approvals: the human gate between an agent proposing an action and performing it. Work-item approvals sit in the same queue as schedule and agent approvals, with assignee, type, and status filters plus due-date sort. The Approval workflow governs their states; connector approval integrations extend the gate to external systems, installed under Integrations. The decision method — what, on what, why, blast radius, policy fit — lives under Approving agent actions.

Agents doing work items

Sessions attach to work items from Starting a session: environment, agent, and work item pickers set the session scope before it starts. Open deliverables on the same surface track work already in flight, so two sessions do not work the same item. Once running, the open-session surface is Sessions; the full how-to is Working with sessions; first-timers start at Your first session.

Work items carry their CRM context with them: the company the work belongs to and the contacts who own and sign off on it. The project tree hangs off the company; the deal pipeline in Sales deals feeds the same relationships. A row with no company cannot be routed.

What next

• Programs: the engagement containers.
• Projects: the project hierarchy under each company.
• Deliverables: the client-facing outputs.
• Tasks: the shared task list.
• My Tasks: the personal slice.
• Templates: repeatable shapes for recurring work.
• Work Item Types: types, fields, and defaults.
• Workflows: the statuses behind every row.
• Approvals: the gate on agent actions.
• Starting a session: attaching the session to its work item.
• Working with sessions: running the session behind an item well.
• Companies: the organizations work hangs off.
• Contacts: the people who own and sign off.