Built-in Fields Reference
Every board in Lifecycle OS comes with a set of built-in fields appropriate for its type. These fields are the standard building blocks of your work items. This guide covers every built-in field — what it does, which board types it applies to, and how to use it effectively.
Common Fields — All Board Types
These fields appear on every board, regardless of type.
Key
Type: Auto-generated identifier — Read-only
A unique, human-readable identifier assigned to each item at creation. Format: PREFIX-123, where the prefix is configured per board (e.g., ENG-, CS-, BUG-).
- Keys are permanent — they never change after creation
- Use keys to reference items in conversation, Slack, commits, and PR descriptions
- Keys are searchable in the command palette and global search
- Displayed in the item detail panel header and in table view columns
Title
Type: Short text — Required
The name or summary of the work item. This is the primary identifier humans use to recognize an item.
- Required at creation — you cannot save an item without a title
- Displayed as the main row text in table view
- Keep titles concise but specific: "Add OAuth login with Google" not "Auth work"
- Titles are searched in the command palette and quick search
Description
Type: Rich text
The full description of the work item. Supports markdown formatting, embedded images, code blocks, and other rich content.
- Use description for acceptance criteria, technical notes, links to context
- Visible in the item detail panel
- Description content is included in global search indexing
Status
Type: Single select — color-coded
The current workflow state of the item. See the Statuses guide for the full list and workflow.
- Status drives what columns appear in a status-grouped kanban
- Status is the most common group-by field on R&D boards
- Statuses have categories: Not Started, In Progress, Done, Cancelled
Priority
Type: Single select — 6 levels
The urgency and importance of the item. 6 levels:
| Priority | Color | Meaning |
|---|---|---|
| Urgent | Red | Drop everything |
| Very High | Orange-red | This week, top of the list |
| High | Orange | Current sprint priority |
| Mid | Yellow | Normal priority work |
| Low | Blue | Next sprint or later |
| Very Low | Gray | Nice to have |
Priority set on a story is inherited by its child tasks and sub-tasks unless overridden.
Assignees
Type: Multi-select (team members)
The team members responsible for this work item. Multiple people can be assigned to a single item.
- Assignees appear as avatars in table and kanban views
- Use the person filter to view items assigned to a specific team member
- Group by Assignee to see workload distribution across the team
Created
Type: Timestamp — Read-only
The date and time the item was created. Automatically set by the system.
Updated
Type: Timestamp — Read-only
The date and time the item was last modified. Updated automatically on every change.
Level
Type: Single select — set at creation
The type of work item. Options depend on board type. For R&D boards: Story, Bug, Task, Sub-task. For Customer Success: Objective, Milestone, Action Item.
- Level is set at item creation and typically does not change
- Level controls which fields are visible (e.g., design status is stories-only)
- Use the Level group-by to see the breakdown of item types on a board
R&D Board Fields
These fields are available on R&D (engineering) boards.
QA Assignees
Type: Multi-select (team members)
The team members responsible for quality assurance on this item. Separate from the development assignees.
- QA is a first-class workflow in Lifecycle OS — not an afterthought
- QA assignees receive notifications when an item reaches QA status
- Group by QA Assignee to review QA team workload
Sprint
Type: Single select (sprints)
The sprint this item is assigned to. Sprints are configured on the Sprints page.
- Unassigned items appear in the "No Sprint" group
- Use the sprint filter to quickly focus any view on a specific sprint
- Sprint assignment can be done inline in table view or dragged in kanban
Project
Type: Single select
The code project (repository, service, or component) this item relates to. Examples: Backend API, Mobile App, Data Pipeline, Chrome Extension.
- Configure project options in Settings → Fields
- Use to filter or group items by codebase area
- Helpful for multi-repo organizations to route work to the right engineering team
Stage
Type: Single select — 3 stages
The deployment environment this item is currently in.
| Stage | Meaning |
|---|---|
| Predev | Design, planning, architecture — not yet in development |
| Dev | Actively being developed or in dev/staging environment |
| Production | Deployed to production |
Stage is separate from Status. QA repeats at each stage — an item goes through QA in Dev and again after deploying to Production.
Design Status
Type: Single select — color-coded — Stories only
Tracks the parallel design workflow for a story. Design work often happens alongside or before engineering. Design Status provides a separate axis to track design progress without conflating it with the engineering workflow Status.
Available on stories only. See the Design Status guide for the full workflow.
Pipeline
Type: Single select — Stories only
The planning stage for a story before it enters active development.
| Pipeline State | Meaning |
|---|---|
| Review | Being evaluated — not yet approved for development |
| Ready | Approved and ready to be pulled into a sprint |
Use pipeline-grouped views to manage your backlog review process.
Estimated Hours
Type: Number
The estimated development time for this item in hours.
- Set by the developer or tech lead during sprint planning
- Displayed in the table and in the item detail panel
- Rolled up into Total Estimated Hours for parent items
Logged Hours
Type: Number
The actual development time tracked for this item in hours.
- Updated as work is completed
- Compared against Estimated Hours to track accuracy and burndown
- Rolled up into Total Logged Hours for parent items
QA Estimated Hours
Type: Number
The estimated time for QA testing this item in hours.
QA Logged Hours
Type: Number
The actual QA testing time tracked for this item.
Total Estimated Hours
Type: Computed rollup — Read-only
The sum of Estimated Hours for this item plus all of its children (tasks and sub-tasks for a story; sub-tasks for a task). This rollup is automatic — you don't set it manually.
Total Logged Hours
Type: Computed rollup — Read-only
The sum of Logged Hours for this item plus all of its children. Useful for seeing actual effort across the full scope of a story.
Commitment Date
Type: Date
The deadline for delivering this item. For R&D items, this is usually a customer-committed delivery date or a release deadline.
Parent
Type: Relation — tasks and sub-tasks only
The parent item. Tasks have a parent story; sub-tasks have a parent task. Displayed in table view and the detail panel.
Use the Parent group-by to view all tasks organized under their parent story.
Customer Success Board Fields
Commitment Date
The date your team committed to delivering an outcome to the customer. Displayed and filtered like other date fields.
Assignees
On CS boards, assignees typically represent the CS team members managing a customer relationship or objective — same field, different context.
Managing Built-in Fields
Built-in fields are enabled by default but can be toggled off per board. Open your board → click the gear icon → Fields tab. Toggle any built-in field off to remove it from views, forms, and the detail panel.
Important: Disabling a built-in field doesn't delete data — if you re-enable it later, existing values are still there. Toggling is non-destructive.
Fixed vs. Toggleable Fields
Two fields are fixed and cannot be disabled:
- Key — the unique identifier; disabling it would break references everywhere
- Level — the item type (Story, Task, Sub-task); fundamental to the hierarchy
All other built-in fields — including Status, Priority, Assignees, Sprint, Stage, QA Assignees, Estimated Hours, Logged Hours, Design Status, Pipeline, and all date fields — can be toggled off per board.
Board admins can enable or disable individual built-in fields per board:
- Open your board → click the gear icon → Fields tab
- Toggle any built-in field off to hide it from the board
- Hidden fields don't appear in table columns, kanban cards, or the item detail panel
Tip: For CS boards, disable engineering-specific fields like Stage, QA Assignees, and Estimated Hours to keep the interface clean and relevant for your CS team.