Short definition
An issue type in Jira is the category that classifies what kind of work an issue represents - Bug, Story, Task, Epic, Sub-task are the standard ones, but admins can create custom types like Incident, Change Request, or Vulnerability. Issue type controls which screen, workflow, and field configuration applies to the issue.
How issue type controls everything else
The issue type field is the dispatcher inside Jira’s configuration model. Once you set it on an issue, Jira looks up:
- Workflow scheme -> which workflow this issue uses (which statuses, which transitions).
- Screen scheme -> which fields appear on Create / Edit / View screens.
- Field configuration scheme -> which fields are required, hidden, or read-only.
- Issue security scheme -> who can see the issue.
- Notification scheme -> who gets emailed on changes.
All of these can be different per issue type within the same project. That’s why “just add another issue type” isn’t a trivial change - the admin has to wire it into every scheme above.
Hierarchy and parent / child relationships
Jira’s default hierarchy is Epic at the top, then Story / Task / Bug at the middle level, then Sub-task at the bottom. The middle level is sometimes called the “standard” level - new custom issue types are added there by default. Advanced Roadmaps / Plans introduces additional levels above Epic (Initiative, Theme) on Jira Cloud Premium and on Data Center.
The parent relationship is automatic:
- Sub-tasks always have one parent issue (a standard-level issue). This is enforced; you can’t create a sub-task without picking one.
- Standard-level issues optionally have an Epic Link / parent pointing to an Epic.
- Epics don’t have a parent in the default hierarchy.
Custom issue types in practice
Common custom types worth creating:
- Incident - different workflow (acknowledge / investigate / resolve), different required fields (severity, affected services, postmortem due date).
- Change Request - different workflow (request / CAB approval / scheduled / implemented), different required fields (rollback plan, change window, approver).
- Vulnerability - different SLA, different security scheme so reports stay scoped to security team.
For STM Issue Templates users: a different sub-task template can be wired to each issue type via an Executor with an issue-type condition. Bugs get triage sub-tasks; change requests get approval and rollback-test sub-tasks; incidents get postmortem sub-tasks - all without manual intervention from the reporter.
See also (Redmoon products)
Common questions
What is an issue type in Jira?
An issue type is the category that classifies what kind of work an issue represents - Bug, Story, Task, Epic, Sub-task are the standard ones, but admins can create custom types like Incident, Change Request, or Vulnerability. Issue type controls which screen, workflow, and field configuration applies to the issue.
What are the default Jira issue types?
Out of the box, Jira ships with Epic, Story, Task, Bug, and Sub-task. Jira Service Management adds Service Request, Incident, Change, Problem, and Post-incident Review. Atlassian recommends using these defaults wherever possible and only adding custom types when the workflow truly differs.
Should I create a new issue type or use a custom field?
Create a new issue type only if the work follows a different lifecycle or needs different fields. If you'd just add an 'Is incident?' yes/no field, use a custom field. If a separate workflow (triage -> investigation -> postmortem) and a separate set of required fields is needed, create the Incident issue type.
Can issue types differ between projects in Jira?
Yes - each project uses an Issue Type Scheme that selects which types are available there. Two projects can use the same workflow but different issue types, or vice versa. Issue Type Schemes are managed under Jira Administration -> Issues -> Issue type schemes.