Workflows
A project workflow scheme defines which reusable workflow each ticket type uses. The resolved workflow controls the statuses a ticket can use and, when configured, the transitions that ticket is allowed to make.
Good workflows make work visible without forcing people to debate the process every time a ticket moves. Use workflow mappings to let different kinds of work follow different lifecycles in the same project.
Workflow Schemes
Each project has a workflow scheme with:
- Ticket types: the active types that can be mapped, such as task, story, bug, epic, and subtask.
- Workflows: reusable workflow definitions with statuses and optional transitions.
- Default workflow: the fallback workflow for ticket types without a specific mapping.
- Mappings: the table that assigns each ticket type to a workflow.
For example, a project can use:
- Default workflow for tasks and stories.
- Bug Triage for bugs.
- Epic Roadmap for epics.
- Subtask Execution for subtasks.
When a ticket is created, edited, moved from the action menu, or dragged on a board, TOW resolves the workflow from the ticket's issue type.
Workflow Page
Open Selected project → Project settings → Workflow to manage the scheme.
The page has two tabs:
| Tab | Use it for |
|---|---|
| Mappings | Assign each ticket type to an existing workflow or start creating a new workflow for that type. |
| Workflows | Review reusable workflows, metadata, mapped ticket types, create workflows, delete unmapped workflows, and open the graph editor. |
The graph editor edits one selected workflow at a time. Template selection and ticket-type mapping happen outside the editor so creation, mapping, and graph editing stay separate.
Statuses
Each workflow status has:
- Key: the stable value used by tickets, TQL, and APIs, such as
in_progress. - Label: the readable name shown in the app, such as
In progress. - Category: todo, in progress, or done.
- Sort order: the order used in status lists and default boards.
The default workflow includes backlog, todo, in progress, blocked, in review, done, canceled, and archived.
TOW automatically ensures an archived status exists. Archived work is treated as done-category work and leaves active operating views unless included by filters.
Status keys are project-wide. If the same status key appears in more than one workflow, it must use the same label and category in every workflow. This keeps boards, filters, and reporting consistent.
Status Categories
Status categories make reporting consistent even when projects use different labels.
| Category | Meaning |
|---|---|
| Todo | Work is not started or is waiting to start. |
| In progress | Work is active, blocked, or under review. |
| Done | Work is complete, canceled, archived, or otherwise closed. |
Use status categories when you want workflow-independent reporting. Use status keys when you need exact project-specific filtering.
Ticket-Type Status Options
Ticket creation, ticket editing, ticket action menus, and board moves only use statuses from the ticket type's resolved workflow.
If a ticket changes from one type to another and the old status is not present in the new type's workflow, TOW remaps the status by category. For example, a story in done can map to a bug workflow's done-category status such as released.
Unsupported statuses are not shown in ticket status menus. If a stale request tries to save a status outside the resolved workflow, the backend rejects it.
Hidden Statuses on Boards
Project boards decide which statuses appear in columns. A status can exist in the workflow without appearing on a given board.
Tickets in workflow statuses that are not mapped to a board column are hidden from that board. They are not deleted. They can still appear in list view, search, TQL results, and other saved boards.
Before removing a status from a board, confirm another board or list process will still review tickets in that status.
When a board column maps statuses from multiple workflows, TOW chooses a valid status for the dragged ticket's issue type. If no status in the column belongs to that ticket's workflow, the drop is blocked.
Open and Restricted Transitions
Workflows can be open or restricted.
- Open workflow: tickets can move between configured statuses without a transition graph.
- Restricted workflow: tickets can move only along configured transitions.
Use open workflows for lightweight teams that need flexibility. Use restricted workflows when compliance, handoffs, quality gates, or role control matters.
Transition Rules
A restricted transition can define:
- Destination status: where the ticket can move next.
- Minimum project role: member, lead, or admin.
- Required fields: fields that must be filled before the move succeeds.
Required fields can include built-in ticket fields such as title, description, issue type, priority, due date, labels, assignee, epic, progress, estimate, and project custom fields such as cf.customer_tier.
If a status change is blocked, TOW leaves the ticket in its current status. The move may require a different source status, a higher project role, or required fields that have not been filled in.
When users cannot move a ticket, check the transition graph and the ticket's required fields before assuming there is a permissions issue.
Required Fields
Required fields are useful for quality gates. For example:
- Require an assignee before moving to
in_progress. - Require a due date before moving to
in_review. - Require customer tier before moving customer work to
done. - Require an epic before moving large work out of backlog.
Keep required fields practical. If a field is required too early, people may enter low-quality data just to move the ticket.
Workflow Templates
Workflow templates can speed setup for common operating models, such as simple delivery, scrum, bug triage, customer support, product discovery, epic roadmap planning, story design-to-delivery, subtask execution, QA verification, release readiness, and change approval.
Create templates from Selected project → Project settings → Workflow → Workflows → Create workflow → From template. The creation wizard shows a template list on the left and a read-only graph preview on the right.
After creating a workflow from a template:
- Review every status label and category.
- Remove statuses your team will not use.
- Confirm transitions match the team's real handoffs.
- Add required fields only where they improve quality.
- Map statuses to project board columns.
Templates are a starting point. The project manager remains responsible for the final workflow.
Creating and Cloning Workflows
The creation wizard supports three paths:
- From template: start with a common lifecycle and then adjust it.
- Clone: copy an existing workflow and edit the copy without mutating the original.
- Empty: start with no statuses and build the graph manually.
If you choose Add new workflow... from a row in Mappings, the new workflow is automatically mapped to that ticket type after creation. If you choose Create workflow from Workflows, the new workflow is created unmapped until you assign it.
Editing Workflows Safely
Before changing a live workflow:
- Review active tickets by status.
- Review which ticket types map to the workflow.
- Confirm saved boards map all statuses that need review.
- Check TQL filters that reference status keys.
- Communicate restricted transition changes to the team.
- Test ticket creation, ticket action menus, and board moves after saving.
Workflow changes affect ticket creation, board moves, list filters, TQL, and reporting. Keep status keys stable when possible so existing filters and references continue to work.