Task and issue workflows

A useful task and issue workflow shows what needs doing, who owns the next action and what makes the work complete. A long, many-coloured board does not. Design it from real handoffs, then configure statuses, issue types and review points to match.

Begin with a real item

Choose a deliverable that recently stalled. Trace it from request to completion: who clarified the request, did the work, reviewed it and accepted the result? Mark where it waited and why, then repeat with a defect or blocker. The paths may share a board but need different information.

A task describes planned work; an issue records a present problem requiring investigation or resolution. A risk is a possible future event and should not quietly become a task marked “in progress”. These are proposed working definitions; the team must agree on them.

Write one sentence for entry and exit at each meaningful stage. “In review” should name who reviews and what they check. “Done” should mean an agreed outcome, not that a contributor has stopped working.

Atlassian’s Jira documentation describes workflows as statuses connected by transitions and separates status, priority and resolution. These concepts are useful even if the team uses another product.

Choose a scheme and its defaults

In Jira company-managed spaces, workflow schemes define the relationship between work types and workflows. A scheme is associated with a space, so different workflows can apply to different combinations of space and work types.

A Jira administrator with global permission can create or edit advanced workflows. Start with the default workflows supplied with the space type you selected; modify or create new workflows later.

Jira Workflow Essentials (Australia)

Treat resolution separately

In Jira, a work item is open or closed by its Resolution field, not its status. It is open if the resolution field is unset; closed if it has a value. Resolution describes how the work was completed.

Keep statuses few and observable

A practical starting sequence might be ready, in progress, waiting for review and done, plus a visible blocked condition. Add a status only if it changes who acts next or how work is reported.

If “awaiting design”, “awaiting content” and “awaiting legal” all mean the same owner is waiting, a single waiting status plus a reason may be clearer. If different teams have distinct queues and service expectations, separate stages can be justified.

Define how an item returns. A reviewer may request changes, sending work back to the owner; a rejected request may be closed with a reason, not sent into an endless loop. Jira’s documented transitions are directional, so a workflow needing a return path must configure one. In any tool, test the path users actually take rather than assuming a drag-and-drop board permits it.

Configure one-way transitions

Jira workflows define how work items move between statuses; a transition must exist for a move between two statuses. Transitions are one-way, so back-and-forth movement requires two separate transitions. A transition can loop, leaving the status unchanged while opening a transition screen or triggering actions.

To add a transition, open the workflow editor, select Add transition in the page header, choose the From and To statuses, name it and select Add. Alternatively, drag a line between two statuses. You can also allow work items in any status to move to that transition.

In team-managed spaces, space admins can create, edit or delete workflows. Each space can have multiple workflows, assigned to specific work types.

Apply rules to transitions

Team-managed Jira workflows can apply rules on transitions. Available rules include assigning a work item to someone, checking a work item’s field, checking whether a work item has been through a status, and updating a work item field. Workflow rules can be added, edited or removed from transitions.

Give issues and risks their own information

An ordinary task should have an outcome, owner and next date or trigger. An issue should include observed impact, evidence, severity or priority, responsible investigator and a resolution. A risk record should describe what may happen, its trigger, likely impact, response owner and when it becomes an issue. Do not use a numerical risk score unless the team has defined how it is estimated and used.

Keep links between records. If an issue creates three repair tasks, do not mark it resolved solely because those tasks exist. If a risk materialises, preserve the earlier assessment and create or identify the actual issue. This separation helps review whether preventive action worked without rewriting history.

Put approvals at genuine gates

An approval is useful when someone other than the worker must decide whether a deliverable can move forward. Record the exact version or output reviewed, the approver and the consequence of rejection. Microsoft Power Automate documents different approval patterns, including everyone approving, first response and sequential approval. Pick the pattern that matches authority; do not let a convenient default decide for the project.

Test a revision after one approval. Does the earlier approval still apply, or must the revised deliverable return to review? Make that rule explicit. A green status should never imply an unreviewed replacement file was accepted.

Keep the backlog visible and owned

Unassigned and old items should appear in a recurring triage view. Decide how long a proposed item may wait before someone confirms whether it remains relevant; the threshold is an internal choice, not an industry constant.

A weekly review can classify items as ready, waiting for information, deferred with a review date or closed with a reason. Atlassian’s backlog view illustrates one way to surface work, but a filter helps only if a person acts on it.

Make closure reversible in the record, not by erasing the decision. If a request returns, a new item or reopened item should show why. Removing abandoned work from the active queue is healthy when the reasoning remains visible.

Jira team-managed spaces have a backlog view listing work items in the Backlog or Sprint lists, plus work items on the team’s board in the Board list. Enabling the backlog adds a Backlog tab; new work items created through the + Create icon appear there. Disabling the backlog moves all work items to the board, placed by current status.

Test with three awkward cases

Before rolling out a workflow, run a normal task, a rejected deliverable and an issue that blocks another task. Ask contributors and approvers to act using ordinary permissions.

Record where the system does not show the next owner or where the required field prompts a guess. Then simplify or adjust the configuration. A workflow succeeds when the team can explain what each status means and find neglected work without private messages.

To view active transitions in company-managed Jira spaces, open a work item and select the status. Choose View workflow from the dropdown.