Most project tools treat the kanban board and the workflow as two separate things: the board is a view, the workflow is a config in a hidden admin screen, and the two drift. Strkr makes the columns the workflow. Add a column, you added a state. Drag a card, you wrote the status transition. The gap between the picture and the model disappears.
Most tools let you add a board and separately configure a workflow. The result is two sources of truth: a workflow definition in a scheme and a visual board the team actually uses. Changes to one quietly diverge from the other. The Strkr model collapses the two: the columns on the board are the workflow states. There is no second place to look, no scheme to debug, no admin console to open.
A column is not a visualization of a state; it IS the state. Add a column called Review and the workflow now has a Review state. Rename it to QA and the state renames everywhere, including historical records. The admin console you were looking for does not exist because the board is the admin console.
Grab a card in Ready. Drop it in In Progress. The issue's status field writes the transition, the audit log records the change with before and after values, any automation bound to the transition fires, and the card settles. One drag, one write, one log entry. No modal, no confirmation.
The workflow is linear by default (left to right across columns). Dragging a column to a new position reorders the workflow for every project using it. The team that discovered QA should sit before Review and not after it reorders in five seconds, not a config commit.
Each column carries optional rules: assignees required before enter, acceptance criteria checked before exit, who has permission to move cards into or out. The rules live on the column, visible on the board header. No separate validator or post-function.
Set the WIP limit on the column directly. The header shows the current count and the cap. Over cap, the header turns amber. The limit lives next to the thing it limits; a manager asking "what is the WIP limit on Review" looks at the header, not an admin screen.
The default flow is left to right, but states can define allowed next states. Blocked can only go back to In Progress or forward to Review. The constraint shows up as a tinted drop-zone when dragging; invalid targets are grayed. The branching is defined on the column, not a separate state diagram.
A workflow is useful because things happen when a card moves. The useful things cross module boundaries: Slack notifications, CRM record updates, downstream task creation, OKR progress ticks. Strkr Flows is the automation engine behind every workflow transition, so the question "what fires when a card enters Done" is one place to look.
Bind a Flow to the "card enters Review" transition. The Flow posts a formatted message in the designated Slack channel with the issue key, title, assignee, and link. The pattern is one node in a visual canvas, not a webhook configured in Jira with a template language.
An issue linked to a CRM ticket writes back on transition to Done: the ticket closes with the resolution note from the issue. The CSM sees the status change in the account timeline without the engineer messaging them. The Flow runs in one database transaction with the status write.
When a card enters QA, a checklist of standard regression tests spawns as subtasks. The QA engineer picks up the issue and the test plan is already attached. The template lives on the column; swapping the template is a dropdown change.
An issue tagged with a Goal (OKR) contributes to the Goal's progress when it transitions to Done. The Goal's KR auto-updates. The weekly check-in on the OKR becomes a glance at the Goals tab, not a reconstruction.
Flows binds not just to column transitions but to time-based conditions. A card past due by three days triggers a nudge; past due by seven, an escalation to the lead. The time-and-status composite condition is a drag-and-drop block, not a cron job and a predicate.
The audit log records every column move with the actor, the time, the from-state, the to-state, and the trigger (human drag or automation). Compliance queries ("show every status change on this issue over the quarter") run against the log, not a reconstruction.
The five-column default (Backlog, Ready, In Progress, Review, Done) works for most engineering teams and ships that way. Marketing, operations, and support teams run different shapes. The patterns below are the ones production tenants are running; each is a template a workspace admin can clone and tweak.
The agile shape with explicit QA. Review is engineering code review, QA is testing. Teams running trunk-based development collapse Review and QA into one column; teams running release trains keep them separate.
Content pipeline shape. Each column has an entry rule: Brief requires a filled brief template, Draft requires an attached draft document, Scheduled requires a publish date. The columns enforce the content hygiene without a separate editorial checklist.
Support ticket shape. The Waiting on Customer column is excluded from SLA timers; the Investigating column's WIP limit is set to the on-call rotation count. The SLA automation on Resolved writes satisfaction survey records.
Vendor lifecycle shape. Each column's entry rule enforces the paperwork: Contract requires an uploaded signed agreement, Onboarding requires W-9 or equivalent, Active requires security review sign-off. Compliance ends up as entry rules rather than a separate checklist.
Candidate pipeline shape. The Rejected state is a terminal column with an optional feedback template. The Offer column has a time-based automation that follows up after seven days without response. The pattern replaces a dedicated ATS for small teams.
Expense or invoice approval shape. Each review column has a permission rule: only managers can move cards out of Manager Review, only finance can move cards out of Finance Review. The approval chain is the column permissions, not a separate workflow approval tree.
Kanban workflows go wrong in predictable ways. Over-configured workflows become their own maintenance burden; under-configured workflows become visual trackers nobody trusts. The Strkr model avoids a set of traps on purpose.
Jira workflow schemes compose workflows across projects, with inheritance and overrides. The result is debugging where a status transition fired by looking at a nested JSON structure. Strkr workflows are per-project or shared workspace-wide, with no inheritance; the trade-off is less composition but far less debugging.
A column's entry rule shows on the column header. A card that failed to enter shows the unmet rule in the error toast. There is no condition hidden behind a workflow configuration editor the user has to find.
What runs when a card enters Done is a Flow with the status-change trigger, visible on the Automations tab. The question "why did this card create a subtask" is answered by opening the Flow, not by inferring from a plugin's post-function list.
Jira splits transition rules into conditions (gates on who can transition) and validators (gates on data correctness). Strkr collapses them: a column entry rule either passes or does not, and shows the user what failed. One concept to understand.
A workflow with active cards can be edited: rename a column, add a column, change a rule. The change applies forward. Historical records keep their original transition labels in the audit log, so renaming a column does not retroactively rewrite audit history.
A project using the shared workspace workflow can fork and own a local workflow at any time, inheriting the current state and then diverging. The fork is one click; the undo (merge back to the shared workflow) is one click. The team is never stuck with a shared workflow they outgrew.
Strkr Projects ships the kanban workflow on the $79 per month tier with transition automations, column rules, branching flows, and audit trail included. No workflow scheme to maintain, no admin console to open.
A board is a visualization; a workflow is a set of states cards move through. Most tools treat them as separate things: the board renders a view, the workflow lives in a config. Strkr collapses them: the columns on the board ARE the workflow states. Adding a column adds a state. Dragging a card writes the transition. The practical difference is that there is no second source of truth to debug; the picture and the model are the same object.
Yes. Each column carries optional entry and exit rules, including permission rules. "Only QA can move cards out of QA" or "Only the project lead can move cards into Done" is a column permission setting. The rule is visible on the column header; a user attempting a disallowed move sees a error toast, not a silent block. The rules compose with the project-level permission model, so an admin always has the override.
By default, cards move left to right across columns in sequence. A column can define its allowed next states, so Blocked can only transition to In Progress or back to Ready, not forward to Review. When dragging a card, invalid drop targets gray out. The constraint is defined on the column, visible to the user, and enforced consistently. Teams running a linear flow never configure next-state rules; teams running the handful of branches typically needed configure them in a few minutes.
The state renames everywhere, including on historical cards and in reporting filters. However, the audit log preserves the original transition label on each historical entry, so an audit query shows the state name at the time of the transition. A card that moved to "Review" when the state was called that, then stayed open after the state was renamed to "QA," shows the original "Review" transition in the log plus the current "QA" state. Nothing is retroactively rewritten.
Yes. A project can use a shared workspace workflow or fork a local copy at any time. The fork inherits the current state and then diverges. Teams running a shared workflow for compliance (one QA process across engineering teams) use the shared version; teams needing a variant fork. The merge-back option exists, so a team that forked for a quarter can rejoin the shared workflow if the fork turned out unnecessary.
Every workflow transition writes to the activity stream, which the Reports tab reads directly. Cycle time (time from entering In Progress to entering Done), lead time (time from Backlog to Done), throughput (cards reaching Done per week), and WIP (open cards per column) all compute from the same event log. There is no separate reporting pipeline; a workflow change is immediately reflected in the metrics the next time the Reports tab renders.
No sales call, no migration consultant, no four-month implementation. Enter your card, get 14 days of the full Pro tier, cancel any time before day 14 with zero charge. Spin up a workspace, import your CSV, and have something useful before lunch.
