Define work types for company-managed projects with schemes

15 min
Advanced

By the end of this lesson, you'll be able to:

  • Configure the work type hierarchy
  • Create a work type
  • Create a work type scheme

Configure work type hierarchy

The work type hierarchy controls how work items interact with each other across Jira. It applies to all work, regardless of their project type or work type scheme. The default configuration is:
1. Epic (the Epic work type)
0. Story (all standard work types, like Story and Task)
-1. Subtask (all Sub-task work types)
This means that an epic can be the parent of standard work. Standard work items can be the parent of sub-tasks. But, a sub-task can’t be the parent of anything. Standard work items can’t be the parent of an epic or other standard work.
👇This is the default work type hierarchy for Jira.
Diagram of the issue type hierarchy. At the highest level, level one, is the epic. Under the epic, at level zero, are standard issue types: Story and Task. Under these issue types, at level minus one, are Sub-tasks. These are the lowest level of the hierarchy.
However, Jira admins can add other levels to this hierarchy.
👉 For example: You want another level above epics. So you add a level two to the hierarchy called “Initiative” and associate your custom Initiative work type to that level.

You can only add levels higher than the Epic level of the hierarchy. You can’t add levels between the defaults or below them. 

Jira admins can also associate more work types with the Epic level or any custom levels in the hierarchy above epic. You can’t remove the Epic work type from the Epic level.
👉 For example: Your custom work type, Program, should be at the same level as epics.

Whenever you modify the work type hierarchy, it can break the existing parent-child relationships across your site. Do so carefully.

To configure the work type hierarchy:
  1. In the upper-right corner of Jira, select the Settings icon (represented by a gear).
  2. Under Jira admin settings, select Work items.
  3. In the sidebar, under Work types, select Work type hierarchy.
  4. To add a level to the hierarchy, select Create level.
  5. This level will be above your existing hierarchy. If you have multiple custom levels, you can name them descriptively.
  6. In the Jira Work Types column, select one or multiple work types from the menu.
  7. If you want to remove a level, select Remove.

If you add a standard work type to the Epic level or a custom level above Epic, it won’t be part of the Story level (level zero).

Create work types

Jira comes with many default work types, including Epic, Story, Task, and Sub-task. Sub-tasks and epics have some unique behavior in Jira.
👇 Click the tabs below to learn more about their behavior.
Epics act as parents for standard work types, like Stories and Tasks. They represent larger bodies of work with many smaller deliverables or stages.
Because of this, users can add child work items from different projects under epics.
👉 For example: An epic in the Mobile project contains child work items from the iOS, Android, and Windows projects.
Reports and dashboards provide insight into these cross-project epics.
These default work types should meet most of your organization’s requirements, but you can create work types as needed.

You can’t create Epic work types, but you can use the work type hierarchy to add work types to the Epic level or above it.

To create a work type:
  1. In the upper-right corner of Jira, select the Settings icon (represented by a gear).
  2. Under Jira admin settings, select Work items.
  3. In the sidebar, under Work types, select Work types.
  4. Select Add work type.
  5. Enter an intuitive name and detailed description so users understand each work type’s purpose.
  6. Select either Standard Work Type (Level 0) or Sub-Task Work Type (Level -1).
  7. Select Add.
  8. If you want to change the avatar for that work type, find it in the list. Next to the work type, select More actions (represented by ···), then Edit.
  9. You can select an avatar from the library or upload your own, then select Close.
  10. Select Update to save your changes.

We recommend you limit the number of custom work types to keep your site configuration clean and straightforward. We also recommend you don’t delete default work types as you can’t ever get them back.

Configure a work type scheme

Create a work type scheme

Work type schemes define which work types are available to associated company-managed projects. Only Jira admins can configure them.
There’s a default work type scheme that automatically updates to include all work types in your site. Because of this, you should avoid associating the default work type scheme with projects, as it will usually have more work types than individual projects need.
To create a work type scheme:
  1. In the upper-right corner of Jira, select the Settings icon (represented by a gear).
  2. Under Jira admin settings, select Work items.
  3. In the sidebar, under Work types, select Work type schemes.
  4. Select Add work type scheme.
  5. Name your scheme and add a detailed description so Jira admins know when to use it.
  6. Drag and drop work types from the Available work types section to the Work types for current scheme section.
  7. For the Default work type, you can leave it as None, or you can select any work type that is in the Work types for current scheme section.
  8. Select Save.

Associate your scheme with a project

To apply the work type scheme, you need to associate it with one or multiple projects. Only Jira admins can associate work type schemes with projects.
When you first create a company-managed project, it will use the default work type scheme for that project template. You can change which scheme a project uses after you create the project.
To associate a work type scheme with a project:
  1. Open the project in Jira.
  2. In the sidebar, next to the project name, select More actions (represented by ···), then Project settings.
  3. In the project settings sidebar, select Work types.
  4. In the upper-right, select Actions, then select Use a different scheme.
  5. Select your scheme, then select OK.

Modify the work type scheme

Work types are a key part of Jira used in many configurations. Adding a work type to a work type scheme can have many impacts.
👇 Click the tabs below to learn more about these impacts.
You might need to set up new workflows. Then, you’ll have to map them to the new work types using the workflow scheme.
If you want to remove a work type from a work type scheme, or delete it entirely, you’ll need to move all work of that type to another work type first. Moving work to a new work type has several components:
  1. Use the Bulk Move operation to efficiently move work items.
  2. Map the status for work to statuses associated with the new work types.
  3. Set values for required fields on the new work types.
  4. Ensure that you save or add any necessary field data from the original work type to the new work items, as new work items may not use all fields from the original work type.
Deleting a work type will impact all filters that reference that work type. They may not be able to return the desired results. Be cautious when deleting work types for this reason.
👇 Watch this video to learn how to carefully modify a work type scheme.

Let’s explore an example

Enzo, a Jira admin, has a request from several software teams. They want to replace the Request work type in their projects with two work types instead: "Internal Request" and "External Request.” When Enzo asks how they want the work types to behave, it’s clear they need different workflows and screens. This seems like a valid reason to create a new work type!
To meet this request:
  1. Create two new work types: Internal Request and External Request.
  2. Add the work types to the projects' work type scheme. Enzo first validates that only the software teams that want these work types use this scheme. Otherwise, he should create a new work type scheme for just these projects.
  3. Bulk move existing work with the Request work type to the Internal Request and External Request work types. Enzo asks for the teams' help to identify which work items are internal and external.
  4. Remove the Request work type from the work type scheme. Because only the software teams' projects use this scheme, this won’t break any other project’s configurations.
  5. Modify other project configurations for this work type, like the workflow scheme, screen scheme, work type screen scheme, layout for work items, and field configuration scheme. Enzo works with the software teams to understand their requirements. He also ensures that no other projects use the schemes he changes.

Enzo could consider renaming the existing Request work type to Internal Request, then only creating one additional work type. But, if other projects, schemes, and filters use the Request work type, they will now see the renamed version. This may not be what they want.

How was this lesson?

next lesson

Define how users see work in company-managed projects with screen schemes

  • Create a screen
  • Create a screen scheme
  • Create a work type screen scheme
  • Associate a work type screen scheme with a project
  • Let’s explore an example!
Go to next lesson

Community

FAQsForums guidelines
Copyright © 2025 Atlassian
Report a problemPrivacy PolicyNotice at CollectionTermsSecurityAbout