The table-stakes problem
Every issue tracker beyond a certain scale has to support configurable workflows. Teams genuinely have different processes. A team shipping a consumer app has a different bug flow than a team shipping firmware. A Scrum team moves work through different states than a Kanban team. An on-call team triages differently than a feature team. Forcing all of these into a single fixed lifecycle — the path Linear takes — works for teams whose process matches the tool’s opinion, and fails for teams whose process doesn’t.
So configurable workflows are table stakes for a tool that wants to serve software teams at large. Bugspot supports them. You define the statuses each work type moves through, you define which transitions are legal between those statuses, and you assign a workflow to a type. A Bug might go Open → Triaged → In Progress → In Review → Verified → Closed. A Task might be To Do → In Progress → Done. That’s your call.
This is where most trackers stop being trackers and start being platforms. It’s worth explaining why, and where we draw the line instead.
The second most common bloat vector
After custom fields, workflow configuration is the most common path from “tracker” to “platform.” The reason is that workflow configuration doesn’t stay contained. Once you expose workflows as a configurable surface, a long tail of adjacent features follows, each one asked for by a real customer with a reasonable-sounding need:
- Workflow conditions. “Only let this transition happen if the Entry has an assignee.” “Only let this transition happen outside of a frozen release window.”
- Workflow validators. “Require a comment when transitioning to Rejected.” “Require a linked pull request before moving to In Review.”
- Workflow post-functions. “When an Entry moves to Done, also assign the Reporter to the Entry.” “When an Entry moves to Verified, clear the resolution field.”
- Transition screens. “Show a different set of fields when transitioning to Resolved than when transitioning to Closed.”
- Workflow permissions, schemes, and scheme overrides. The layered system that decides which workflow applies to which type in which project for which role.
Jira has all of these. Each was added because a customer needed it. Collectively, they form an admin surface area that no small team can reason about — and a support burden where every conversation starts with “well, in our instance the workflow is configured to…”
The individual requests are legitimate. The cumulative cost is a product that can’t be understood.
Where we draw the line
Our rule is simple: the workflow engine handles structure, not logic.
Structure means: what states exist, which transitions are legal, and who can trigger each transition. That’s three things. An admin can hold all three in their head. A new engineer joining a team can understand the workflow by looking at it.
Logic means: conditions, validators, post-functions, transition-specific screens, and anything that behaves like scripting. That’s the long tail. Once it’s in the product, it’s in the product forever, and every feature you build afterward has to account for it.
So Bugspot’s workflow engine gives you states, transitions between states, and role-based permissions on transitions. Nothing else. If a team wants “only QA can mark something Verified,” that’s a permission on the transition — the QA role is required to trigger it. No scripting, no conditions beyond role checks, no callbacks.
This means some things Jira can do, Bugspot can’t. A team that wants to require a comment on every rejection has to establish that as a team norm, not as a system-enforced rule. A team that wants to auto-clear a field on transition has to do it manually or via the API. We’re accepting these tradeoffs deliberately. The tradeoff for every feature we add to the workflow engine is that the next feature gets easier to justify, and the one after that, and we’ve seen where that path ends.
Predefined workflows: ship a few good ones
The other workflow question is how many predefined templates to ship. It’s tempting to ship many — one for Scrum, one for Kanban, one for bug triage, one for security response, one for support escalation, one for release management, one for each popular methodology. Every template makes the tool look more capable in a comparison chart.
We’re going to ship three.
A basic Kanban workflow. A basic Scrum workflow. A bug lifecycle workflow. Teams use them as-is or fork them. That’s it.
Why three? Because the cost of a predefined workflow isn’t zero. Every template we ship, we have to maintain, document, support, and evolve as the product evolves. Teams that pick a template tend to accept its opinions, which means the templates become load-bearing — users expect them to stay stable. Shipping ten templates means ten templates to keep good. Shipping three means three templates that are actually good.
Teams whose process doesn’t fit one of the three can fork the closest match and edit it. The workflow engine is structural and small, so forking is cheap. This is the right place to put the flexibility: in the ability to modify a template, not in the number of templates we ship.
What this means for you
If you’re evaluating Bugspot and your team has a genuinely unusual process — a multi-stage QA gate, a hardware-software coordination flow, a regulated-industry release checklist — you’ll be able to model it, because the workflow engine is real. States, transitions, role permissions on transitions. All the structural pieces are there.
If you’re evaluating Bugspot and your team wants to enforce process rules via the tool — required fields on transition, automated field updates, conditional gates — Bugspot won’t do that, and won’t grow into doing it. Those rules live in team practice, in code review, in the kind of thing a tech lead catches. We think that’s where they belong anyway. A tool that enforces process rules tends to accumulate them until no one remembers which rules apply where, and the team ends up routing around the tool to get work done.
Structure, not logic. Three templates, not ten. A workflow engine you can understand by looking at it. That’s the line, and we’re going to hold it.