Projects

Organize work into projects within programs and portfolios.

What Is a Project?

A project is the workspace where a team does its day-to-day work. Every task in Work Ops belongs to exactly one project, and every project provides its own backlog, boards, workflows, and configuration. Projects are the primary organizational boundary — they determine which workflows apply, which task types are available, and who receives notifications.

When you create a project, you assign it a globally unique key — a short uppercase code like PROJ, IOS, or INFRA. This key becomes the prefix for every task created in the project. A task in the IOS project might be IOS-1, IOS-2, and so on. Keys are permanent, human-readable, and make it immediately clear which project a task belongs to, even when referenced outside the platform.

The Three-Tier Hierarchy

Projects do not exist in isolation. They sit within a three-tier hierarchy that maps to how organizations typically structure delivery:

Portfolio

A portfolio is the highest organizational level. It provides an executive-level rollup across multiple programs, giving leadership a single view of all work happening within a business unit or strategic initiative. Portfolios are ideal for tracking overall delivery health, resource allocation across programs, and alignment with strategic goals and OKRs.

A portfolio contains one or more programs.

Program

A program groups related projects that contribute to a shared outcome. The program level is where cross-project coordination happens — a program manager can see work across all projects in the program, create cross-project boards for visibility, and track dependencies between teams.

For example, a "Mobile App Relaunch" program might contain separate projects for the iOS app, Android app, backend APIs, and design system. The program provides the connective tissue that keeps these teams aligned.

A program belongs to a portfolio and contains one or more projects.

Project

The project is where the team works. It contains the backlog of tasks, the boards for managing flow, the sprint history, and all configuration for how work moves through the system. Most team members spend the majority of their time operating at this level.

A project belongs to a program.

Project Configuration

Each project is independently configurable to match the team's needs. The key configuration areas include:

Default Workflow

Every project has a default workflow that determines how tasks move between statuses. The default workflow applies to all task types unless overridden by a workflow scheme. This means a simple project can use one workflow for everything, while a complex project can assign different workflows to different task types.

Task Types

Projects choose which task types are available to their team. A support-focused project might enable only Bug and Task, while a product development project might use Story, Epic, Bug, and Sub-task. Limiting available types keeps the creation experience clean and prevents misuse.

Notification Schemes

Notification schemes control who gets notified about task events and through which channels. You can configure notifications for events such as task creation, status changes, assignment changes, comments, and approaching due dates. Different roles (assignee, reporter, project lead, watchers) can receive different notification sets.

Field Configurations

Field configurations determine which fields appear on task creation and editing forms, which fields are required, and which are optional. This lets you enforce data quality — for example, requiring a priority and component on every new bug — without cluttering forms with fields the team does not use.

Custom Task Creation Forms

Projects can define custom forms for creating tasks. These forms control which fields appear, their order, default values, and any help text. Different task types within the same project can have different creation forms.

Custom forms are especially useful when non-technical users submit work requests. A bug report form might ask for steps to reproduce, expected behavior, and actual behavior, while a feature request form might ask for a user story, acceptance criteria, and business justification.

Archiving Projects

When a project is no longer active — perhaps the product was retired or the initiative completed — it can be archived. Archiving makes the project and all its tasks read-only. No new tasks can be created, existing tasks cannot be modified, and the project no longer appears in active project lists.

Archiving is reversible. If work resumes, the project can be unarchived and returned to full functionality. All historical data, including tasks, comments, attachments, and audit history, is preserved intact.

Components

Components represent logical parts of the product or codebase that a project's team owns. Each project defines its own set of components. Common examples include:

• Frontend — The user interface layer
• API — Backend services and endpoints
• Database — Data storage and migrations
• Authentication — Login, sessions, and security
• Infrastructure — Deployment, CI/CD, and hosting

Components serve two purposes. First, they help categorize tasks so the team can filter and report on work by area. Second, each component can have a default assignee — when a new task is tagged with that component, the assignee is automatically set to the component's owner. This ensures that work is routed to the right person without manual triage.

Labels

Labels provide lightweight, cross-cutting categorization for tasks. Unlike components, labels do not carry assignment logic or represent ownership. They are flexible tags that help teams slice and filter work in ways that components alone cannot cover.

Labels are scoped at four levels, controlling where they are available:

This scoping system prevents label sprawl. Teams can create project-specific labels freely without polluting other projects, while organization-wide labels are managed centrally.

Bringing It Together

A well-configured project gives the team a streamlined workspace where the right task types are available, workflows enforce the team's process, notifications keep the right people informed, and components route work automatically. At the same time, program and portfolio managers get aggregated views without requiring teams to change how they work.

Start by creating a project, assigning it to a program, defining a few components, and choosing a workflow. You can refine the configuration as the team settles into its rhythm.