Workflows

Define how tasks move through statuses with conditions, validation, and automation.

What Is a Workflow?

A workflow is a state machine that controls how tasks move between statuses. Rather than allowing anyone to set any status at any time, workflows define exactly which transitions are permitted, what conditions must be met, and what actions happen automatically when a transition occurs.

Workflows are the backbone of process enforcement in Work Ops. They ensure that your team's agreed-upon process is followed consistently — whether tasks are updated through boards, forms, API calls, or automation rules. Every status change goes through the workflow.

Statuses

A status represents a position that a task can be in — such as Open, In Progress, In Review, Done, or Cancelled. Statuses are the building blocks of workflows.

Every status belongs to one of four categories. These categories are used by the system to understand the nature of each status for reporting, board behavior, and metric calculations:

Statuses are defined globally and shared across workflows. This means the In Progress status is the same object whether it appears in a software development workflow or a content publishing workflow. This consistency enables cross-project reporting and board standardization.

Workflow States

A workflow state binds a status to its position within a specific workflow. While statuses are global, workflow states are local to a workflow. The same In Progress status might behave differently in two workflows — one might allow a direct transition to Done, while another might require going through In Review first.

When you build a workflow, you select which statuses to include and then define transitions between the resulting workflow states. Not every status needs to appear in every workflow — a simple workflow might use only three statuses, while a complex one might use ten.

Transitions

A transition is a rule that permits a task to move from one workflow state to another. Transitions are directional — a transition from In Progress to In Review does not automatically create a transition from In Review back to In Progress. Each direction must be defined explicitly.

Every transition has a name that describes the action being taken, such as "Start Work," "Submit for Review," "Approve," or "Reject." These names appear in the user interface as the available actions on a task.

Transitions can include three types of components that control their behavior:

Conditions

Conditions are rules that must be true for the transition to be available. If a condition is not met, the transition does not appear as an option — the user cannot attempt it at all.

Examples of conditions:

• Only the assignee can perform this transition
• Only users in the "Approvers" group can approve
• The task must have at least one sub-task
• All sub-tasks must be in a Done or Cancelled status
• The task must belong to a specific component

Conditions control who sees the transition and when. They are evaluated before the user attempts the transition, filtering the available actions to only those that are currently valid.

Validators

Validators are checks that run when the user attempts the transition. Unlike conditions (which hide the transition entirely), validators allow the transition to be attempted but reject it if the check fails, providing a specific error message explaining what needs to be corrected.

Examples of validators:

• A resolution must be selected (required when closing a task)
• The time spent must be greater than zero (ensuring time was logged before completing)
• A comment must be provided explaining the reason for the transition
• All required custom fields must be filled in
• The due date must be set

Validators enforce data quality at the point where it matters most — during the status change that would make missing information a problem.

Post-Functions

Post-functions are actions that execute automatically after a transition completes successfully. They handle side effects and automation so the team does not have to remember manual steps.

Examples of post-functions:

• Notify all watchers that the task's status has changed
• Set the resolution field to "Done" when moving to the Closed state
• Clear the assignee when moving a task back to the backlog
• Update the task's "last transitioned" timestamp
• Trigger a webhook to notify an external system
• Add a comment recording who performed the transition and when

Post-functions run after validation passes, so they can assume the transition is legitimate. They execute in order and are guaranteed to run — there is no way for a user to skip them.

Transition Screens

Some transitions need to collect information from the user before they can complete. Transition screens are optional UI prompts that appear when a transition is triggered, presenting a form where the user can provide the required data.

Common uses for transition screens include:

• Resolution screen — When closing a task, prompt the user to select a resolution (Done, Won't Fix, Duplicate, etc.) and optionally add a closing comment.
• Assignment screen — When escalating a task, prompt the user to select who should take over.
• Time logging screen — When completing a task, prompt the user to log their remaining time.
• Rejection reason screen — When rejecting a review, require the reviewer to explain what needs to change.

Screens work hand-in-hand with validators. A screen collects the data, and validators ensure the data meets requirements before the transition proceeds.

Wildcard Transitions

A wildcard transition is reachable from any state in the workflow. Instead of defining a source state, a wildcard transition applies globally — no matter what state a task is currently in, the wildcard transition is available.

The most common wildcard transitions are:

• Cancel — Allows a task to be cancelled from any state. Without a wildcard, you would need to create a "Cancel" transition from every individual state.
• Reopen — Allows a closed or cancelled task to be reopened from any terminal state.

Wildcard transitions still support conditions, validators, and post-functions. For example, a "Cancel" wildcard might have a condition that only project leads can cancel tasks, a validator requiring a cancellation reason, and a post-function that notifies the assignee.

Workflow Schemes

A workflow scheme maps different workflows to different task types within a project. This allows a single project to use different processes for different kinds of work.

For example, a software development project might use:

Every workflow scheme has a default workflow that applies to any task type not explicitly mapped. This ensures that even if a new task type is added to the project, it has a workflow immediately without requiring a scheme update.

Automation Rules

Automation rules extend workflows with event-driven logic that fires automatically when specific things happen. Each rule has three parts:

Trigger

The event that starts the rule. Triggers fire on observable events within Work Ops:

• Task created — A new task is added to the project
• Task updated — A field on a task changes (priority, assignee, labels, etc.)
• Status changed — A task transitions to a new status
• Comment added — Someone comments on a task
• Sprint started or ended — A sprint is activated or closed
• SLA breached — A task exceeds its service-level target
• Due date approaching — A task's due date is within a configurable threshold

Condition

An optional filter that narrows when the rule fires. The trigger might fire on every task creation, but the condition can restrict the rule to only Critical bugs, or only tasks in a specific component, or only tasks assigned to a specific team.

Examples of conditions:

• Priority is Critical or High
• Task type is Bug
• Component is "Production Systems"
• Assignee is unset
• Label includes "customer-reported"

Action

What happens when the trigger fires and the condition is met. Actions are the automated response:

• Assign the task — Set the assignee to a specific person or the component's default assignee
• Change a field — Update priority, labels, due date, or custom fields
• Transition the task — Move the task to a different status (the transition's conditions and validators still apply)
• Add a comment — Post an automated comment, useful for logging why an action was taken
• Send a notification — Notify specific people or channels about the event
• Trigger a webhook — Call an external service for integrations beyond the platform

Putting It Together

Here are some practical automation rule examples:

Designing Effective Workflows

A well-designed workflow balances process enforcement with team agility. Here are principles to guide workflow design:

• Model your real process. Workflows should reflect how work actually moves through your team, not an aspirational process that no one follows. Observe your team's current habits and encode them.
• Keep it simple. Every additional status and transition adds cognitive overhead. A workflow with four or five statuses is usually sufficient. Add complexity only when there is a demonstrated need.
• Use validators sparingly. Requiring data at every transition creates friction. Reserve validators for transitions where missing data would cause real problems — like requiring a resolution when closing a task.
• Leverage wildcard transitions. Common actions like "Cancel" and "Reopen" should be wildcards rather than duplicated across every state. This reduces maintenance and ensures consistency.
• Automate the tedious. If team members always perform the same manual step after a transition (like notifying a channel or clearing a field), encode it as a post-function. Automation reduces errors and saves time.
• Review and iterate. Workflows are not set in stone. As your team's process evolves, update the workflow to match. Regularly review whether statuses are being used and whether transitions are causing unnecessary friction.