JIRA Priorities and Resolutions
Every issue answers two quiet questions. How urgent is the work? How did the work end? Priority answers the first question, and resolution answers the second. Both fields guide daily planning and keep reports honest.
Layman's View: A Hospital Emergency Room
Nurses sort arriving patients by urgency. A serious injury jumps ahead of a mild cough. That sorting equals priority. After treatment, the record states the outcome, such as "recovered" or "referred elsewhere". That outcome equals resolution.
Issue arrives --> Priority set --> Work happens --> Resolution set (new bug) (High) (In Progress) (Done)
Priorities
Priority tells the team which issue deserves attention first. JIRA starts with five levels.
Default Priority Levels
| Priority | Meaning | Sample Situation |
|---|---|---|
| Highest | Work stops until someone fixes it | Website down for all customers |
| High | Serious problem with no easy workaround | Payments fail for some users |
| Medium | Normal work with a standard schedule | Report page loads slowly |
| Low | Minor problem with little impact | Typo in a help article |
| Lowest | Nice-to-have improvement | Slightly different button colour |
Administrators can rename levels, add new ones, or change icons to match the company style.
Resolutions
Resolution records the outcome of a finished issue. An open issue leaves the field empty, and JIRA shows it as Unresolved.
Common Resolution Values
| Resolution | Meaning |
|---|---|
| Done | The team completed the work |
| Won't Do | The team decided not to build or fix it |
| Duplicate | Another issue already covers the same problem |
| Cannot Reproduce | The team could not trigger the reported problem |
Status vs Resolution
New users often mix up these two fields. Status shows where an issue sits in the workflow right now. Resolution shows how the issue ended.
Status and Resolution Compared
| Point | Status | Resolution |
|---|---|---|
| Question answered | Where is the issue now? | How did the issue end? |
| Changes often | Yes, with each transition | No, set once at the end |
| Open issues | Show To Do or In Progress | Stay empty |
| Example values | In Review, Done | Done, Duplicate |
Priority vs Severity
Severity measures damage, and priority measures urgency. A crash on a rarely used admin screen carries high severity and low priority when only one person uses that screen. A spelling mistake on the home page carries low severity and may deserve medium priority, since every visitor sees it. JIRA ships with a Priority field. Teams that want severity add a custom field.
Searching by Priority and Resolution
priority IN (Highest, High) AND resolution = Unresolved resolution = Duplicate AND created >= -30d
The first query lists urgent open work. The second query shows duplicates from the past month and reveals how often reporters submit repeated tickets.
Healthy Habits
- Reserve Highest for real emergencies. A board full of Highest tickets hides the true emergency.
- Agree on written rules for each level, so every reporter sets priority the same way.
- Review priorities during backlog meetings, since urgency changes over time.
- Choose a resolution with care. Reports count Duplicate and Done differently.
Real-World Example
A support team receives forty tickets on Monday. The lead sorts the board by priority and sees two Highest items, six High items, and the rest at Medium or lower. Two engineers take the Highest tickets at once. By Friday, thirty-five tickets carry the resolution Done, three carry Duplicate, and two carry Cannot Reproduce. The weekly report shows exactly how the work ended.
Summary
Priority ranks the urgency of work, and resolution records the outcome. Status sits between them and tracks the current stage. Clear rules for each level keep boards trustworthy. Searches on both fields reveal urgent work and patterns in how issues end.