6.5 Team-Managed Workflows, Statuses & Workflow Rules
Key Takeaways
- In team-managed projects, the project admin edits each issue type's workflow from Project settings > Issue types and confirms which issue types the updated workflow applies to.
- New team-managed statuses get an 'Any status' transition by default; limits are 100 statuses per project and 50 per workflow.
- Each transition can hold up to 10 rules: assign, restrict by field value, restrict by previous status, restrict who can move, validate a permission, copy a field, or update a field.
- Team-managed statuses and rules affect only that project, while company-managed workflows are global and shared through workflow schemes.
- Deleting a transition deletes its rules, and deleting a role breaks any rule that references it.
6.5 Team-Managed Workflows, Statuses & Workflow Rules
Blueprint objective 4.2 covers team-managed workflows: configuring workflows for issue types, creating and configuring statuses, and configuring workflow rules. Team-managed projects don't use workflow schemes or the company-managed rule catalogue. The project admin edits everything inside the project, and changes affect that project only.
Where Team-Managed Workflows Live
In a team-managed project, each issue type has a workflow, and you edit it from the issue type:
- Open Project settings > Issue types (Work types) and select the issue type.
- Select Edit workflow.
- Add or change statuses, transitions, and rules in the workflow editor.
- Select Update workflow, then confirm which issue types the workflow applies to.
Team-managed projects can have several workflows, for example a lightweight flow for tasks and a review-heavy flow for bugs. Because you confirm the issue types on save, you control whether a change applies to one issue type or to all that share the workflow.
| Topic | Company-Managed | Team-Managed |
|---|---|---|
| Who edits | Jira admin (or a holder of Edit workflows, if the workflow isn't shared) | Project admin of that project |
| How a workflow reaches issue types | Workflow scheme maps issue types to workflows | Chosen per issue type when you update the workflow |
| Statuses | Global objects shared across the site | Belong to the project |
| Rule catalogue | Full restrict / validate / action rule set, properties, and events | A smaller set of team-managed rules |
| Scope of a change | Every project using the workflow | Only this project |
Statuses in Team-Managed Workflows
- Creating a status: add it in the workflow editor and choose its category (To Do, In Progress, or Done).
- Default transitions: a new status automatically allows issues in any other status to move into it. The Any status label on the diagram represents this global transition.
- Limits: Atlassian allows up to 100 statuses across all of a project's workflows and up to 50 statuses in any one workflow.
- Renaming a status affects only that project. Company-managed projects are untouched, which is very different from renaming a global company-managed status (Chapter 10).
- Boards follow the workflow. Team-managed boards are tied to the project's statuses, so adding, renaming, or removing statuses shows up as board columns. Map every "finished" status to the rightmost column so sprints count them as complete.
Editing and Deleting Transitions
You can replace an Any status transition with more restrictive transitions (for example, only In Review can move to Done). Atlassian warns that tightening transitions can cause errors when people drag cards across the board, because some moves are no longer allowed. Deleting a transition also deletes the rules attached to it.
Team-Managed Workflow Rules
Rules are added to a transition, and each transition can hold up to 10 rules. The available rules are:
| Rule | What It Does | Example |
|---|---|---|
| Assign a work item | Sets the assignee when the transition runs: the reporter, the current user, no one (unassigned), or a specific person | Moving to In Review assigns the issue to the QA lead |
| Restrict to when a work item is a specific value | Allows the transition only if a field compares as configured (equals, contains, greater than, is before, and so on) | Only allow Approve when Budget is 5,000 or less |
| Restrict to when a work item has been through a status | Allows the transition only if the issue has (or, with Reverse this rule, has not) been through a status. Options: include the current status, only consider the most recent status, ignore looped transitions | Only allow Done if the issue has been through In Review |
| Restrict who can move a work item | Limits the transition to the assignee, reporter, a chosen user, a role, a group, or people with a specific permission | Only the Quality assurance role can move issues out of In Review |
| Validate that people have a specific permission | Checks a Jira permission (for example, Close Issues) before the transition runs | Only people with Close Issues can move work to Done |
| Copy the value of one field to another | Copies a field within the issue, or from the parent issue to the child. Depending on field type, the copy appends or replaces | Copy the epic's Target quarter down to each story |
| Update a work item field | Sets text, number, label, date, or time fields. Text is appended; date and time fields are set to the moment of the transition | Stamp Handed to QA with the transition date |
Two behaviors are easy to miss:
- Rules that don't apply are skipped, not failed. For example, a copy rule skips issues that lack either field or have no parent.
- Removing a role breaks the rules that reference it. If a Restrict who can move rule points to a deleted role, the team may be unable to move issues until the rule is updated.
Worked Scenario
A team-managed software project wants: (1) only QA engineers can mark work done, (2) nothing reaches Done without passing In Review, and (3) the date of the QA hand-off recorded automatically.
- Create a custom project role QA engineer (duplicate Member and adjust permissions) and add the testers.
- On the transition into Done, add Restrict who can move a work item (role: QA engineer) and Restrict to when a work item has been through a status (In Review, with Include the work item's current status and Only consider the most recent status selected).
- On the transition into In Review, add Update a work item field to set the Handed to QA date.
- Update the workflow and confirm the issue types it applies to.
No Jira admin, workflow scheme, or permission scheme is involved. That's the core difference the exam tests.
A team-managed project wants only members of its custom 'Release manager' role to move work items into the 'Deployed' status. What should the project admin configure?
A team-managed project admin adds a new 'Blocked' status to the Bug workflow and selects Update workflow. Without any further changes, which issues can move into 'Blocked'?
A team-managed project's workflow rule copies 'Target quarter' from the parent to each story. A story with no parent is moved across the board. What happens to that story?