How to Build Custom Workflows with Task States (Beyond TODO/IN-PROGRESS/DONE)

Your workflow isn't a straight line from "not started" to "done." Real work involves waiting for approvals, getting blocked by dependencies, circling back for revisions, and navigating complex processes. Yet most task managers force you into three rigid states: TODO, IN-PROGRESS, DONE.

This mismatch creates friction. You end up using workarounds—adding "[BLOCKED]" to task titles, creating fake "Waiting" tags, or manually tracking status in notes. Your task manager becomes a glorified checklist instead of a true workflow management system.

Custom task states solve this problem. Instead of conforming your work to three predefined boxes, you design states that reflect your actual process: DESIGN → DEVELOPMENT → CODE REVIEW → TESTING → STAGING → DEPLOYED. Or DRAFT → EDITING → CLIENT REVIEW → REVISIONS → PUBLISHED. Or RESEARCH → PROPOSAL → APPROVED → IN-PROGRESS → DELIVERED.

To-Track offers unlimited custom states with powerful features:

• Create states matching your workflow (BLOCKED, WAITING, REVIEW, etc.)
• Group states into categories (OPEN / ACTIVE / CLOSED)
• Restrict transitions with tag-based rules (only "tested" tasks can deploy)
• Enable cascading state changes (closing parent closes active children)

This guide shows you how to design custom workflows that match your reality, not your software's limitations.

The Problem with Three-State Systems

Traditional task managers (Todoist, Things, Asana Basic) enforce a simple model:

TODO → IN-PROGRESS → DONE

This works for trivial tasks ("Buy milk") but breaks down for knowledge work:

Software Development Reality

Actual workflow:

1. BACKLOG: Idea captured, not prioritized
2. TODO: Prioritized, ready to start
3. IN-DEVELOPMENT: Actively coding
4. CODE REVIEW: Waiting for peer review
5. BLOCKED: Dependency issue, can't proceed
6. TESTING: QA is testing the change
7. STAGING: Deployed to staging environment
8. READY FOR PRODUCTION: Approved, awaiting deploy window
9. DEPLOYED: Live in production
10. DONE: Verified working, task closed

Three-state compromise:

• BACKLOG → TODO (lose prioritization context)
• IN-DEVELOPMENT, CODE REVIEW, TESTING → IN-PROGRESS (lose visibility into where tasks actually are)
• DEPLOYED → DONE (can't distinguish "deployed" from "verified working")

Result: Your task list shows 15 items as "IN-PROGRESS" when only 3 are actually being coded. The rest are blocked, in review, or waiting deployment. You have zero visibility.

Content Creation Reality

Actual workflow:

1. IDEA: Topic captured
2. OUTLINE: Structure drafted
3. FIRST DRAFT: Writing in progress
4. SELF-EDIT: Revising your own work
5. EDITOR REVIEW: Sent to editor
6. REVISIONS: Implementing feedback
7. FINAL REVIEW: Editor approval
8. SCHEDULED: Ready to publish on date
9. PUBLISHED: Live on website
10. PROMOTED: Shared on social media

Three-state compromise: Everything from OUTLINE to REVISIONS becomes "IN-PROGRESS," hiding whether you're blocked on editor feedback or actively writing.

Sales Pipeline Reality

Actual workflow:

1. LEAD: Contact identified
2. QUALIFIED: Budget/need confirmed
3. DEMO SCHEDULED: Meeting booked
4. PROPOSAL SENT: Quote delivered
5. NEGOTIATION: Discussing terms
6. AWAITING SIGNATURE: Contract sent
7. WON: Deal closed

Three-state compromise: QUALIFIED through NEGOTIATION = "IN-PROGRESS," making it impossible to prioritize follow-ups.

The pattern: Real workflows have 7-15 meaningful states. Three states force you to lose critical context.

To-Track's Custom State System

To-Track removes the artificial limit. You design workflows that match reality.

Core Concepts

1. Unlimited Custom States

Create as many states as your process needs:

• Default states: TODO, IN-PROGRESS, DONE
• Add custom: BLOCKED, REVIEW, TESTING, DEPLOYED, etc.
• No arbitrary limits

2. State Categories

Every state belongs to a category:

• OPEN (0): Not started yet (TODO, BACKLOG, IDEA)
• ACTIVE (1): Currently being worked on (IN-PROGRESS, REVIEW, TESTING)
• CLOSED (2): Finished (DONE, CANCELLED, ARCHIVED)

Categories enable:

• Automatic time tracking for ACTIVE states (live timers)
• Recurring task reset logic (when entering CLOSED state)
• Cascading parent-child state changes

3. State Ordering

States within each category have an order:

• Defines which state is "next" for swipe gestures
• Controls which state tasks reset to for recurring tasks
• Visual organization in state selector

4. Tag-Based Transition Rules

The killer feature: restrict which tasks can enter certain states based on tags.

Example: Only tasks tagged "qa-approved" can move to PRODUCTION state.

This enforces workflow rules automatically—no manual gatekeeping needed.

Building Your First Custom Workflow

Let's design a software development workflow from scratch.

Step 1: Identify Your Actual States

Map your real process. Ask:

• What stages does work go through?
• Where does work sit waiting?
• What approvals or checkpoints exist?

Example states:

1. BACKLOG
2. TODO
3. IN-DEVELOPMENT
4. CODE REVIEW
5. BLOCKED
6. IN-TESTING
7. READY TO DEPLOY
8. DEPLOYED
9. DONE

Step 2: Categorize States

Assign each state to OPEN / ACTIVE / CLOSED:

OPEN (not started):

• BACKLOG (ideas, not prioritized)
• TODO (prioritized, ready to start)

ACTIVE (in progress):

• IN-DEVELOPMENT (coding)
• CODE REVIEW (awaiting review)
• BLOCKED (waiting on dependency)
• IN-TESTING (QA testing)
• READY TO DEPLOY (approved, waiting for deploy window)

CLOSED (finished):

• DEPLOYED (live in production)
• DONE (verified working)

Step 3: Define Transition Rules (Optional)

Add tag-based rules to enforce quality gates:

Rule 1: Only tasks tagged "code-reviewed" can move to IN-TESTING Rule 2: Only tasks tagged "qa-approved" can move to READY TO DEPLOY Rule 3: Only tasks tagged "deployed" can move to DONE

Implementation in To-Track:

1. Navigate to Task States Settings
2. Tap on "IN-TESTING" state
3. Add required tag: "code-reviewed"
4. Repeat for other states

Now, if you try to move a task without the required tag to a restricted state, it won't appear as an option. The workflow is automatically enforced.

Step 4: Create the States

In To-Track:

1. Settings → Task States
2. Select category (OPEN / ACTIVE / CLOSED)
3. Enter state name (e.g., "BLOCKED")
4. Tap "Add"
5. Repeat for each state

Result: Your task manager now reflects your real workflow.

Advanced Workflow Patterns

Pattern 1: Blocked State with Visibility

Problem: Tasks get blocked by dependencies (waiting for API access, design approval, client feedback). In three-state systems, blocked tasks sit in "IN-PROGRESS," obscuring what's actually being worked on.

Solution: Create a BLOCKED state (ACTIVE category).

Benefits:

• Time tracking: See how long tasks spend blocked (e.g., "18 hours waiting for design")
• Visibility: Filter by BLOCKED state to see all dependencies at once
• Prioritization: Review blocked tasks weekly to unblock them

Setup:

1. Create state "BLOCKED" in ACTIVE category
2. When a task is blocked, move it to BLOCKED (not IN-PROGRESS)
3. Add note explaining the blocker ("Waiting for API key from DevOps")

Reporting: Export time logs, calculate % of time spent BLOCKED vs. IN-PROGRESS. If tasks spend 40% of time blocked, that's a process problem to fix.

Pattern 2: Review States with Tag Requirements

Problem: Work shouldn't move to production without peer review, but manual enforcement is error-prone.

Solution: Create CODE REVIEW state with tag requirement.

Setup:

1. Create states: IN-DEVELOPMENT → CODE REVIEW → IN-TESTING
2. Add tag requirement to IN-TESTING: must have "reviewed" tag
3. When code review is done, reviewer adds "reviewed" tag
4. Task can now transition to IN-TESTING

Enforcement: Tasks without "reviewed" tag simply can't move to IN-TESTING. The app prevents invalid transitions.

Pattern 3: Approval Pipelines

Problem: Multiple approval stages (manager → director → VP) need tracking.

Solution: Create approval states with tag-based progression.

States:

• SUBMITTED
• MANAGER APPROVED
• DIRECTOR APPROVED
• VP APPROVED
• APPROVED

Tag requirements:

• MANAGER APPROVED requires "manager-ok" tag
• DIRECTOR APPROVED requires "director-ok" tag
• VP APPROVED requires "vp-ok" tag

Workflow:

1. Submit task → SUBMITTED state
2. Manager reviews, adds "manager-ok" tag → MANAGER APPROVED
3. Director reviews, adds "director-ok" tag → DIRECTOR APPROVED
4. VP reviews, adds "vp-ok" tag → VP APPROVED

Progression is automatic based on tagging—no manual state juggling.

Pattern 4: Parallel Workflows

Problem: Different types of tasks (bugs vs. features) have different workflows.

Solution: Use tags to fork workflows.

Setup:

1. Tag tasks "bug" or "feature"
2. Create state-specific to bugs: INVESTIGATING, HOTFIX
3. Create states specific to features: DESIGN, PROTOTYPE
4. Use tag requirements:
   • INVESTIGATING requires "bug" tag
   • DESIGN requires "feature" tag

Result: Bugs follow one path (TODO → INVESTIGATING → HOTFIX → DONE), features follow another (TODO → DESIGN → PROTOTYPE → IN-DEVELOPMENT → DONE).

Pattern 5: Cascading State Changes (Parent-Child)

Problem: When a project (parent task) is cancelled, all subtasks should also close—but manual updates are tedious.

Solution: To-Track's automatic cascading logic.

How it works:

• Close parent → All ACTIVE children automatically close
• Activate child → Parent automatically activates (if not already)
• Deactivate parent → All ACTIVE children move to OPEN state

Example:

• Parent: "Website Redesign" (IN-PROGRESS)
  • Child: "Design mockups" (IN-PROGRESS)
  • Child: "Frontend development" (TODO)
  • Child: "Backend integration" (BLOCKED)

Action: Mark parent as CANCELLED

Result:

• "Design mockups" → CANCELLED (was ACTIVE, so cascaded)
• "Frontend development" → remains TODO (was OPEN, not affected)
• "Backend integration" → CANCELLED (was ACTIVE)

Benefit: One action updates the entire project hierarchy.

Real-World Workflow Examples

Example 1: Agile Software Development

States:

1. BACKLOG (OPEN): Ideas, not prioritized
2. TODO (OPEN): Prioritized for sprint
3. IN-PROGRESS (ACTIVE): Actively coding
4. CODE REVIEW (ACTIVE): Awaiting peer review (requires "code-complete" tag to enter)
5. BLOCKED (ACTIVE): Dependency issue
6. IN-TESTING (ACTIVE): QA testing (requires "reviewed" tag)
7. READY TO DEPLOY (ACTIVE): Approved for production (requires "qa-approved" tag)
8. DEPLOYED (CLOSED): Live in production
9. DONE (CLOSED): Verified, task closed

Tag requirements:

• CODE REVIEW → IN-TESTING: "reviewed" tag
• IN-TESTING → READY TO DEPLOY: "qa-approved" tag

Example 2: Content Creation

States:

1. IDEA (OPEN): Topic captured
2. OUTLINE (OPEN): Structure ready
3. WRITING (ACTIVE): First draft in progress
4. SELF-EDIT (ACTIVE): Author revising
5. EDITOR REVIEW (ACTIVE): Sent to editor
6. REVISIONS (ACTIVE): Implementing feedback
7. SCHEDULED (ACTIVE): Approved, waiting publish date
8. PUBLISHED (CLOSED): Live on site
9. PROMOTED (CLOSED): Shared on social

Tag requirements:

• EDITOR REVIEW → REVISIONS: "editor-feedback" tag
• REVISIONS → SCHEDULED: "final-approved" tag

Example 3: Design Projects

States:

1. BRIEF (OPEN): Requirements received
2. RESEARCH (OPEN): Gathering inspiration
3. SKETCHING (ACTIVE): Initial concepts
4. DESIGN (ACTIVE): High-fidelity mockups
5. CLIENT REVIEW (ACTIVE): Awaiting feedback
6. REVISIONS (ACTIVE): Implementing changes
7. APPROVED (CLOSED): Client sign-off received
8. DELIVERED (CLOSED): Files handed off

Tag requirements:

• DESIGN → CLIENT REVIEW: "design-complete" tag
• REVISIONS → APPROVED: "client-approved" tag

Example 4: Sales Pipeline

States:

1. LEAD (OPEN): Contact identified
2. QUALIFIED (OPEN): Budget/need confirmed
3. DEMO SCHEDULED (ACTIVE): Meeting booked
4. PROPOSAL SENT (ACTIVE): Quote delivered
5. NEGOTIATION (ACTIVE): Discussing terms
6. AWAITING SIGNATURE (ACTIVE): Contract sent
7. WON (CLOSED): Deal closed
8. LOST (CLOSED): Opportunity lost

Tag requirements:

• PROPOSAL SENT → NEGOTIATION: "decision-maker-engaged" tag
• NEGOTIATION → AWAITING SIGNATURE: "terms-agreed" tag

Time Tracking Benefits of Custom States

Custom states supercharge time tracking by revealing where time is actually spent.

Visibility Example

Three-state system:

• IN-PROGRESS: 32 hours total

Custom states breakdown:

• IN-DEVELOPMENT: 8 hours (actual coding)
• CODE REVIEW: 12 hours (waiting for reviewers)
• BLOCKED: 10 hours (waiting for API access)
• IN-TESTING: 2 hours (QA testing)

Insight: Only 25% of "in progress" time is active work. The rest is waiting. This is actionable data—hire more reviewers, streamline API provisioning, etc.

State-Based Reporting

With custom states, you can answer:

• "How long do code reviews take on average?" (12 hours)
• "What % of tasks get blocked?" (60%)
• "How much time is spent in revisions vs. initial work?" (Revisions: 4h, Initial: 10h → 28% rework)

These insights are impossible with TODO/IN-PROGRESS/DONE.

Best Practices for Custom Workflows

1. Start with 5-7 States, Grow as Needed

Don't create 20 states on day one. Start with the most important distinctions:

• TODO
• IN-PROGRESS
• BLOCKED
• REVIEW
• DONE

Add more (TESTING, DEPLOYED, etc.) as you identify gaps.

2. Keep State Names Short and Clear

Good: REVIEW, BLOCKED, TESTING Bad: "Waiting for Client Approval and Feedback", "Currently Being Developed"

Short names work better in UI, especially on mobile.

3. Use Tags to Distinguish Sub-States

Instead of creating 10 states for every nuance, use tags:

States: IN-PROGRESS Tags: "frontend", "backend", "bug", "feature"

Filter by "IN-PROGRESS + bug" to see bugs in progress without cluttering your state list.

4. Review and Refine Quarterly

Workflows evolve. Every 3 months, review:

• Are there unused states? (Delete or consolidate)
• Are tasks getting stuck in certain states? (Process problem to fix)
• Do you need new states? (Add as process changes)

5. Document State Meanings

For teams or future you, document what each state means:

BLOCKED: Work cannot proceed due to external dependency (API access, design approval, etc.). Add note explaining blocker.

CODE REVIEW: Code complete, awaiting peer review. Assign reviewer via note.

Clear definitions prevent misuse.

Migrating from Simple to Custom States

Already using a three-state system? Here's how to transition:

Step 1: Audit Current "IN-PROGRESS" Tasks

List all tasks currently marked IN-PROGRESS. Ask:

• Which are actively being worked on right now?
• Which are waiting (blocked, in review, etc.)?
• Which are in different phases (design vs. coding vs. testing)?

Step 2: Create New States Based on Reality

Identify 3-5 distinct states that emerge from your audit:

• ACTIVELY WORKING
• WAITING FOR REVIEW
• BLOCKED
• TESTING

Step 3: Recategorize Existing Tasks

Move tasks from IN-PROGRESS to their actual state:

• "Build feature X" → IN-DEVELOPMENT (you're coding now)
• "Fix login bug" → BLOCKED (waiting for API key)
• "Update homepage" → REVIEW (awaiting design approval)

Step 4: Adopt New Workflow

Going forward, use granular states instead of lumping everything into IN-PROGRESS.

Result: Immediate visibility improvement.

Conclusion: Your Workflow, Your States

The three-state model (TODO/IN-PROGRESS/DONE) is a software constraint masquerading as best practice. Real work doesn't fit three boxes—it flows through approvals, blockers, reviews, and stages unique to your domain.

Custom states liberate you from this constraint. With To-Track, you design workflows that match your reality:

• Unlimited states: 3, 7, 15, whatever you need
• Tag-based rules: Enforce quality gates automatically
• Cascading changes: Parent-child state syncing
• Time tracking: See where time actually goes (BLOCKED vs. ACTIVE work)

Whether you're a developer navigating code review → testing → deployment, a writer moving through drafts → edits → publication, or a salesperson tracking leads → demos → contracts, your workflow deserves better than generic states.

Stop conforming your work to your software's limitations. Build workflows that reflect how you actually work.

FAQ

Q: How many states should I create? A: Start with 5-7 core states. Add more only as you identify genuine distinctions. More isn't always better—clarity is.

Q: Can I delete or rename states? A: Yes. Renaming preserves all existing tasks in that state. Deleting a state requires reassigning tasks to another state first.

Q: What happens to default states (TODO, IN-PROGRESS, DONE)? A: They remain and cannot be deleted (system defaults). You can add custom states alongside them.

Q: Can the same state have different tag requirements for different tasks? A: No—tag requirements are global per state. If "PRODUCTION" requires "qa-approved" tag, it applies to all tasks. Use separate states if workflows differ (e.g., "PRODUCTION-BACKEND" vs. "PRODUCTION-FRONTEND").

Q: Do custom states work with recurring tasks? A: Yes. When a recurring task completes (enters CLOSED category), it resets to the first OPEN state (usually TODO).

Q: Can I reorder states? A: Yes. Drag states within their category to reorder. Order affects swipe gesture "next state" logic.

Q: How do tag-based rules work with parent-child cascading? A: If a parent closes and tries to cascade children to CANCELLED, but CANCELLED requires a tag children don't have, they'll move to the first available CLOSED state instead.

Q: Can I export state transition data? A: Yes. State logs are in the SQLite database. Export to CSV to analyze state transitions, time per state, etc.

---

Ready to build workflows that match your reality? Download To-Track and design custom states that finally make sense.