Works records tasks, deliverables and other work, including ownership, dates, states, decomposition and connections.
The work entry is what gets done, held as a record — including the states most tools flatten away: blocked, rework, the transitions themselves. This manual covers the entry, its lifecycle, its decomposition, and its wiring.
What you record
The work entry
| Field group | What it holds |
|---|---|
| Identity | Name, description, reference code, the slug the platform addresses it by |
| Classification | The type (task, deliverable, milestone, issue — your operation's types), status, resolution, priority, urgency |
| The lifecycle | Start date, due date, actual start, completed date, estimated and actual duration (minutes) |
| Flow | The workflow it travels, the progress percentage |
| People | The creator, the primary assignee |
| Structure | Parent (for decomposition: parent/child, depth, child count) |
| Recurrence | Whether it repeats, the recurrence rule and description |
| Place | The location the work anchors to |
The states that matter: blocked and rework are first-class, not "in progress" with a note. When a work item waits on a decision, you record that; when it comes back, the return is a transition on the same record — how often work returns, and from where, becomes readable instead of invisible.
Decomposition
Work entries form parent/child trees: a deliverable decomposes into tasks, a milestone into the works that reach it. The tree is data — depth, child counts, progress rolling up — so "is this on track?" answers from the records, not from a status meeting.
Recurrence
Repeating work is defined once, with its rule, and occurs as governed instances — the weekly report, the monthly review — not as manually re-typed entries.
What you can do
- List, search, filter — by type, status, priority, assignee, project, dates; bulk actions
- Create, update, view — the standard screen patterns; the validation and permissions configured for the operation
- Decompose — parent/child structure with rolled-up progress
- Track the lifecycle honestly — the typed states and transitions, including blocked and rework
- Relate — the wiring below
What it connects to
| Target | Examples of the connection |
|---|---|
| Employees | The assignee, the creator, the contributors |
| Projects | The project instance the work belongs to |
| Calendar events | The meetings that advance it, the deadline occurrences |
| Communication | The threads that discuss it |
| Venues & locations | Where the work happens |
| Other works | Parent/child, dependencies, related items |
Typed natures, main-connection flags, ordering, descriptions — governed records, as everywhere.
Where it feeds
Works are Process Orchestration's first-party evidence: where work waits, where it returns, where it completes — the flow readings draw from these records. The evidence story is not separate from your daily work; it reads it. The record you maintain honestly (including the blocked days) helps make delivery readings interpretable.
The pattern note: same four-part structure — record, do, connect, feed. The works manual is where the honest-lifecycle pattern shows: the platform treats blocked and rework as data worth holding, which is the difference between a status board and production evidence.
Implementers configure your operation's work types and lifecycles at adoption — which states matter to you, which transitions need approvals; consultants help align the lifecycles with how work actually moves in your organisation.
No record is an island
Every work entry relates to the people who carry it, the events that advance it, the threads that argue it, the project it serves. Held together, these connections are what turn "a list of tasks" into the delivery story — and the readings read the story.
Review the record and its context before deciding what to do next.
Calendar → · Venues → · All manuals → · The Works platform page →
Check your work
For blocked work, record the actual obstacle and the person or decision needed next. Keep the relationship to its project and supporting exchange. Review completed work as well as recorded transitions: a changed status is a useful operational record, not independent proof of quality or business impact.
Available screens and actions depend on your deployment and permissions. Use this manual alongside the configured workflow and the capability demonstration for your installation.