CONTEXT_OSALPHA

Work items

Plan, track, and organize the team's work with hierarchy, statuses, assignees, and execution.

Purpose

Work items are Allye's unit of work. They turn an intention into something that can be prioritized, assigned, tracked on a board, and related to other items. This guide covers an item's lifecycle for people and agents.

Prerequisites

  • Be authenticated and have an active team.
  • Have Work Items view permission to inspect data.
  • Have create permission to add items and edit permission to change existing items.
  • To associate items with another team, board, or sprint, have access to the destination context.

Key concepts

Types and hierarchy

Allye provides the Epic, Feature, Story, Task, Subtask, Bug, Hotfix, and Spike types. The hierarchy helps keep the right level of detail:

  • Epic: broad objective or initiative.
  • Feature: product capability within an epic.
  • Story: deliverable outcome or need.
  • Task/Subtask: execution work, with a subtask used to break down a task.
  • Bug: incorrect behavior to fix.
  • Hotfix: urgent correction with a limited scope.
  • Spike: investigation or experiment to reduce uncertainty.

An item can have a parent and children. The detail page shows the child count and completed progress, and lets you create or reorder child items when the team's hierarchy workflow allows the type combination.

Status and workflow

Status belongs to the team's workflow. The application may show names such as Backlog, To Do, In Progress, Code Review, QA, Done, or Cancelled, but a team can use a preset with different names. Always use the label shown for the active team rather than a fixed list.

Priority and planning

Priorities are Critical, High, Medium, and Low. An item can also have story points, size, hour estimates, hours worked, remaining hours, dates, work category, tags, environment, component, and repository.

In teams using the Sprint methodology, the Sprint field appears in item planning. In Kanban teams, sprint-specific fields are hidden.

Create a work item

  1. Open Work Items and confirm the active team.
  2. Select New work item.
  3. Enter a clear, outcome-focused title.
  4. Choose the type and priority.
  5. Add a Markdown description when the context does not fit in the title.
  6. Select Create.
  7. Open the item you created to complete the assignee, status, dates, tags, parent, board, or sprint.

The quick form starts with essential fields. The remaining fields are edited in the drawer or on the full item page.

Create a child

  1. Open the parent item.
  2. In the Child Items section, select Add item.
  3. Choose a type allowed by the hierarchy workflow.
  4. Enter the title and confirm with Enter or the confirmation button.
  5. Drag children to reorder them when order matters.

The application checks the type combinations allowed by the team. If a type does not appear, it is a restriction of the current hierarchy model, not a typing error.

Update and track an item

  1. Open the item from the list, board, or detail view.
  2. Edit the title or description directly.
  3. In the side panel, change status, assignee, reviewer, QA, priority, and planning data.
  4. Set start, due, and completion dates when applicable.
  5. Add tags and metadata to support search and filtering.
  6. Consult the Activity section to follow comments and changes.
  7. Use attachments when an image or file is needed to explain the work.

The full page is useful for sharing an item's context; the drawer is faster for a focused update.

Search, filter, and organize

In the work item list, use:

  • Search by title, key, or tags.
  • Filters by type, priority, status, and assignee.
  • An option to show only items assigned to you.
  • Sorting by priority, status, creation, update, or title.
  • Selection of visible columns.
  • A toggle between active items and completed or cancelled items.

By default, the list hides completed and cancelled items. Enable Completed when you need to review history or find a closed item. Filters and columns are persisted per user.

Work in batches

  1. Select several items in the list or board.
  2. Review the number selected.
  3. Choose an available batch action, such as updating priority, assigning, moving, or deleting.
  4. Confirm destructive actions.
  5. Refresh the list if another person or agent changed the same set during the operation.

On the board, batch selection can move items to another column or change priority. On mobile, the same actions appear in the contextual bar.

For agents

An agent should treat the item key, title, team, parent, and status as minimum context before changing anything.

Recommended flow:

  1. Find the item by key or title in the active team.
  2. Read the description, children, priority, assignees, and activity.
  3. Check the current workflow and choose an allowed status.
  4. Make the smallest change that satisfies the request.
  5. Report the item key, what changed, and what remains pending.
  6. When creating a hierarchy, confirm the parent before creating the child.
  7. For batch actions, describe the filter and affected count before executing.

Do not treat a status name from another team as universal. When creating a Story or Task, prefer a specific title and a description that lets another person continue the work without recovering hidden context.

Current states and limitations

Current state: the interface implements CRUD, hierarchy, filters, inline editing, batch actions, comments, reactions, attachments, and association with boards and sprints. The availability of some data and rules is determined by the connected service and the user's permissions.

  • The set of statuses is configurable by team; historical aliases such as to_do, in_review, testing, and released still appear for compatibility.
  • The quick creation form offers Epic, Feature, Story, Task, and Bug; other types may be available in the list, child quick add, or board configuration.
  • Completed and cancelled items are hidden by default in the list, but remain available through the corresponding filter.
  • Without management permission, create, edit, and delete operations are generally limited to the user's own team.
  • Some queries use an empty fallback when the service does not respond; an empty list should not automatically be interpreted as “there are no items.”
  • The board and list can open the same item by an internal identifier or displayed key. For automations, confirm the returned item before executing a mutation.
  • The list's dedicated grouping is still shown as unavailable; use hierarchy, filters, and sorting to organize the view.

Next steps