10.2 Statuses, Resolutions, Priorities & Sub-tasks: Global Configuration
Key Takeaways
- Company-managed statuses are global, so renaming one changes it in every workflow, board, and project that uses it; team-managed status renames affect only that project.
- Never create a resolution named 'Unresolved' or 'None'; any value in Resolution makes Jira treat the issue as resolved.
- Priority schemes decide which priorities each company-managed project offers; the default scheme contains all priorities and can't be edited or deleted.
- Removing a priority from an in-use scheme, or deleting a resolution, requires mapping existing issues to another value.
- Sub-tasks are enabled by default and can be disabled only after existing sub-tasks are converted to standard issue types.
10.2 Statuses, Resolutions, Priorities & Sub-tasks: Global Configuration
Blueprint objective 7.3 covers four global lists that Jira admins maintain: statuses, resolutions, priorities, and sub-tasks. The recurring exam theme is impact. These objects are shared across the site, so renaming, deleting, or disabling one affects every company-managed project that uses it. Team-managed projects behave differently.
Statuses
Where: Settings > Issues (Work items) > Statuses, or directly in the workflow editor.
- Creating: give the status a name, an optional description, and a category (To Do, In Progress, or Done). The category drives colors, progress bars, and
statusCategoryJQL. - Company-managed statuses are global. A status can appear in many workflows. Renaming it changes the label in every workflow, board column, and project that uses it. Check saved filters, board quick filters, automation rules, and integrations that refer to the old name as text. (JQL's
WASoperator still matches historical values by the name configured at the time of the change, or by the status ID.) - Changing a status's category changes how every project reports it. For example, moving "Blocked" from In Progress to Done makes blocked work look finished in progress bars.
- Deleting: a status can be removed from the site only when no workflow uses it. In the workflow editor, deleting a status that still has issues makes you move those issues to another status first.
Renaming Statuses in Team-Managed Projects
Team-managed statuses belong to their project. Renaming one changes only that project's workflow and board. It doesn't touch company-managed statuses or other team-managed projects, even if they have a status with the same name. This is the answer to "What is the impact of renaming a workflow status in a team-managed project?"
Resolutions
Where: Settings > Issues (Work items) > Resolutions (under Work item attributes). Jira admin only, and company-managed projects only.
- The Resolution field records why an issue reached done, for example Fixed, Won't Do, Duplicate, or Cannot Reproduce.
- Add a resolution with the form below the list. Edit changes the name or description everywhere. Delete asks which resolution to move affected issues to.
- Never create resolutions called "Unresolved" or "None". Jira shows Unresolved when the field is empty. An issue with a custom "Unresolved" value counts as resolved, which breaks open-issue filters and reports.
- Hiding resolutions on a transition: the workflow property
jira.field.resolution.exclude(with resolution IDs, comma-separated) removes specific resolutions from that transition's screen. For example, you might hide Duplicate on a Deploy transition. - Translations: resolutions (like statuses) can be translated for users working in other languages.
Priorities and Priority Schemes
Where: Settings > Issues (Work items) > Priorities and Priority schemes.
- Priorities are global values (Highest, High, Medium, and so on) with a name, description, icon, and color. Renaming a priority changes it on every issue and project that uses it.
- Priority schemes decide which priorities each company-managed project offers:
- Jira ships a default priority scheme that contains all priorities and is associated with all projects until you change it. You can't edit or delete the default scheme.
- A custom scheme lists a subset of priorities and can Set as default one of them, which new issues get.
- Removing a priority from a scheme that projects are using, or moving a project to a scheme without some of its current priorities, requires mapping existing issues to a priority that remains.
- You can't delete a scheme while projects are associated with it.
- No default set? Jira still gives new issues a priority. Atlassian says it picks one dynamically from the middle of the list.
Sub-tasks: Enabling, Creating, and Disabling
Where: Settings > Issues (Work items) > Sub-tasks (under Work types).
- Sub-tasks are enabled by default.
- Create sub-task issue types (for example, Dev Sub-task or QA Sub-task) here. Optionally add a new type to an issue type scheme so projects can use it.
- Edit a sub-task type's name, description, and avatar. Renaming affects every project that uses it.
- Delete a sub-task type safely by first bulk-changing its issues to another type.
- Disable sub-tasks: Atlassian requires you to convert existing sub-tasks to standard issue types first. You can't disable sub-tasks while any sub-tasks still exist.
- Parent control: the Sub-task Blocking rule (restrict based on the status of sub-tasks) on a parent's transition stops the parent from closing until its sub-tasks reach chosen statuses.
Impact Summary
| Change | Impact |
|---|---|
| Rename a company-managed status | New label in every workflow, board, and project that uses it; check text references in filters and automation |
| Rename a team-managed status | That project only |
| Change a status's category | Changes progress displays and category-based JQL everywhere the status is used |
| Add a resolution named "Unresolved" | Issues given that value count as resolved; avoid it |
| Delete a resolution | Jira asks which resolution to move its issues to |
| Rename a priority | New label on every issue that uses it |
| Remove a priority from an in-use priority scheme | Existing issues must be mapped to a remaining priority |
| Disable sub-tasks | Allowed only after existing sub-tasks are converted to standard issue types |
A Jira admin renames the global status 'QA' to 'In Test' in a company-managed site. Which outcome should the admin expect?
An admin wants to turn off sub-tasks for the whole site, but the Disable option can't be used. What must happen first?
A service team created a resolution named 'Unresolved' and sets it when agents pause work. Now paused issues vanish from the 'Open work items' filter and show as resolved in reports. What is the best fix?