Work Item Field Reference

Overview

A work item carries a rich set of fields. This reference explains each one: what it's for, how it behaves, and where it shows up in the dashboard and history. Use it when you want to make the most of an item beyond a title and a stage.

Identity and content

Title (required) The name of the work. It's the only required field and is used to generate the item's URL-safe key.

Short description A one-line summary shown on the card face — keep it scannable.

Description The full detail: context, acceptance criteria, links. There's ample room for a complete brief.

Item type A category that groups similar work, such as `task`, `docs`, `content`, `admin`, or `workspace`. Types help you filter and reason about a mixed board. If you don't set one, items default to `task`.

State and priority

Status The item's state. In normal use, status mirrors the column the card sits in — moving a card to Review sets status to `review`. You can set it explicitly if you need a state that differs from the stage name. New items default to `planned`.

Priority Urgency, one of Low, Medium, High, or Critical (defaults to Medium). High and Critical items feed the dashboard's High priority count and are visually flagged in queues.

Sort order The item's position within its column. Moved cards are placed at the end of the target column; you can reorder within a stage.

People

Owner The single person accountable for the item. Shown on the card and in tables.

Assignees The people working on the item, stored as a list (entered as a comma-separated field in the form). Owner answers "who's responsible?"; assignees answer "who's doing it?"

Scheduling

Start date When work is expected to begin.

Due date When the work is due. Drives the Today, Upcoming, and Completed queues and the dashboard's Overdue and Due today counts.

Target release When the work is expected to ship. Shown as a Target chip on the card; useful for release planning distinct from the working due date.

Organization and linking

Labels Free-form, color-coded tags for filtering and grouping (e.g. `seo, public, pricing`). Stored as a list; managed alongside StretchTasks.

Dependencies Other items this one waits on. Recording dependencies makes it clear why something can't start yet and helps you sequence a plan.

Delivery standards

KB required / Ops Doc required / Changelog required Three booleans that mark documentation obligations: a public KB article, an internal Ops Doc, and a release Changelog entry. They appear as chips on the card and roll up into the dashboard's Docs required and Changelog required counts. See Documentation Flags and Delivery Standards.

Access and notes

Client visible Controls whether an individual item is exposed to a client-facing view. Combined with a board's visibility, it governs what clients can see. See Client Visibility, Workspace Access, and Data Isolation.

Internal notes Internal-only detail that stays with the delivery team — a good place for context you don't want a client to read.

Example

A fully specified item might be: Title "Rebuild pricing page", Type content, Priority High, Owner Dana, Assignees Dana, Sam, Due next Friday, Target release in two weeks, Labels content, pricing, public, Dependency "Finalize pricing," Related brand StretchCreative, KB required on. On the board it shows a High chip, a KB chip, and a Target date; in the dashboard it counts toward High priority and Docs required.

Tips

At minimum, set Title, Priority, and a Due date — that's enough to make an item useful everywhere in the app.
Use Owner for accountability and Assignees for the working team; keeping them distinct pays off in status reviews.
Record Dependencies as you find them — they're the fastest way to explain a stalled card.
Put anything client-sensitive in Internal notes, not the description.