How to Set Up Custom Workflows in Linear
Linear ships with a default workflow that covers the basics: Backlog, Todo, In Progress, Done, Canceled. For most teams, this is not enough. Your actual process probably includes stages like In Review, QA, Staging, or Blocked that need explicit representation so issues do not get stuck in ambiguous states. Custom workflows in Linear let you model your real process instead of forcing your process into a generic template.
The goal of a custom workflow is not to add complexity but to add clarity. Every status should correspond to a distinct stage where different people are responsible for moving the issue forward. This guide walks through designing a workflow that reflects your team's actual process and setting up automations so issues transition smoothly without manual status updates.
Step-by-step guide
Map your team's actual development process
Before touching Linear settings, document the real stages an issue goes through from creation to deployment. Talk to your engineers, designers, and QA team. Common stages include Triage, Backlog, Ready for Dev, In Progress, In Review, QA, Ready to Deploy, and Deployed. Write these down in order and note who is responsible at each stage. The workflow should model reality, not an ideal process you wish you had.
Configure custom statuses in team settings
Go to your team settings in Linear and navigate to the Workflow section. Add, rename, or reorder statuses to match the stages you mapped. Assign each status to the correct category — Backlog, Unstarted, Started, or Completed — because Linear uses these categories for cycle tracking and velocity calculations. Keep the total number of statuses between 5 and 8 to avoid over-complicating the board.
- Remove any default statuses your team does not use
- Add statuses like In Review and QA with descriptive names
- Assign each status to the correct category for accurate metrics
Set up automation rules for status transitions
Linear's automations can move issues automatically based on triggers. Set up rules like: when a pull request is opened, move the issue to In Review; when the PR is merged, move it to QA or Ready to Deploy. Go to Settings > Team > Automations and configure the GitHub integration triggers. These automations reduce the manual burden of updating issue status and keep your board accurate in real time.
Configure SLA indicators for time-sensitive statuses
For statuses where issues should not linger, set up SLA warnings. Linear allows you to configure time-based alerts — for example, if an issue stays In Review for more than 48 hours, it gets flagged. This visibility helps team leads identify bottlenecks before they cascade. Focus SLAs on handoff statuses where issues are most likely to stall waiting for someone else.
Create filtered views for each workflow stage
Build saved views for the statuses that matter most to different team members. Engineers need a view of In Progress issues assigned to them. Team leads need a view of issues In Review for more than a day. QA needs a view of issues in the QA status sorted by priority. Saved views make the workflow actionable by showing each person exactly what they need to act on.
- Create a My Review Queue view filtered to In Review issues where the user is reviewer
- Create a Blocked Issues view filtered to the Blocked status with sort by last updated
- Create a Ready to Deploy view for release managers
Document the workflow for the team
Add a description to each custom status in Linear explaining what it means and what action moves an issue to the next status. For example, the In Review status description should say Code is submitted as a PR and awaiting reviewer approval. Merge the PR to move to QA. This documentation lives inside Linear itself so it is visible to anyone hovering over a status, not buried in a wiki.
Common mistakes
Creating too many statuses
Every status you add is a decision point where issues can stall. If your workflow has 12 statuses, issues will get lost in intermediate states. Keep it to 5-8 statuses and use labels or custom fields for additional metadata like Blocked Reason rather than creating a Blocked By Design and Blocked By Engineering status.
Not assigning statuses to the correct category
Linear calculates cycle velocity and completion metrics based on status categories (Backlog, Unstarted, Started, Completed). If your In Review status is categorized as Unstarted instead of Started, your velocity numbers will be wrong. Verify category assignments after any workflow change.
Building a workflow around an ideal process nobody follows
If your team skips QA for small fixes but you enforce a QA status on every issue, people will game the system by instantly moving through it. Design the workflow for how your team actually works and iterate as the process matures.
Forgetting to set up automations for GitHub integration
If developers have to manually update Linear when they open or merge PRs, the board goes stale within hours. The GitHub-Linear integration automations are the single highest-value workflow configuration because they keep the board accurate without developer effort.
Tips
Use Linear's sub-issue feature for tasks within a status rather than creating extra statuses — for example, keep a single In Review status and track individual reviewer approvals as sub-issues.
Set the default status for new issues to Triage rather than Backlog so that every issue gets an explicit prioritization decision before entering the backlog.
Review your workflow metrics monthly — if a status consistently has a high average time, it indicates a bottleneck worth investigating.
Use Linear's project-level workflows to override team defaults when a specific project has a different process, like a migration that skips QA.
How Vantage helps
Vantage pushes tickets to Linear with dependency-aware wave assignments that map to your custom workflow stages. When tickets are generated from a PRD in Vantage, they arrive in Linear with the right priority, dependencies, and context so your workflow statuses reflect real progress rather than manual guesswork.