Configurations overview: Understanding Jira schemes

As a Jira administrator, you are responsible for a large number of projects with different settings and views. The more projects you manage, the greater the risk of configuration conflicts — and the more difficult it is to keep track of them all.

For example, you manage a project whose workflow you also want to use for another project. How do you proceed? Or you have defined that the field "Editor" is mandatory in screen A, but irrelevant in screen B. What do you do? Or you want to change the selection of the issue types for several masks afterwards. Can't you do that easily and quickly?

Yes, you can.

For all these use cases and questions, there is one answer: Jira schemes. When configuring Jira, they are an important part, but often cause confusion. However, that doesn't have to be.

In this article, we'll give you the ultimate overview of Jira schemes and finally bring clarity to this complex topic.


What are Jira schemes?

First, a scheme is a concept that has certain characteristics and can be applied to one or more cases over and over again. A Jira schema is a collection of values that can be used by one or more Jira projects. And this is precisely the power of schemes: the configurations you’ve spent a long time fine-tuning only need to be done once. As soon as a next project is created for which your configurations would be best suited, you can apply the created scheme for the new project with just a few clicks.

If you are an administrator with only a few projects, you may think that you would rather manually configure settings for each project individually. But once you manage numerous projects, adjusting settings manually (afterwards) is a time-consuming task. Jira schemes save time and provide standardized procedures.

Here you can see an overview graphic we created about Jira schemes:

To better understand the graphic, let’s start at the smallest project unit (on the right) and work our way to the left until we arrive at the largest unit, “Project”.

Jira Fields and Jira Screens

On the far right of the graphic, you can see “Screens” and “Fields”. When Jira users in your team want to create a new project, they click on “Create” and see a screen similar to this one:

In our view, the fields “Project”, “Issue Type” and “Summary” are mandatory. The “Epic Link” field, on the other hand, is not required to be filled in. This default is not located in the screen, but in the setting of the field, the field configuration (in the graphic we now go one step to the left).

Field Configuration (Scheme)

You can configure the fields as you wish. For each field, you specify whether it is a required field, if you can enter text or numbers, and the overall appearance of the field. You define these settings in the field configuration. They can be put into a scheme to manage fields across multiple projects, issue types, and screen masks. So one scheme can be used for many cases and saves you from manually creating the layout for each new screen.

Note: The field configuration belongs to the field itself and not to the screen template!

Issue Type Screen Scheme

In our graphic, we move to the center, to the Issue Types and their schemes. An “Issue Type Screen Scheme” establishes the relationship between a project and the available issue types. This ensures that the correct screens are used for each issue type.

In our example, you can see two different configurations with different end results.

  1. Screen Scheme for Story: A story has an arbitrary number of fields, which are created by “create”. When the story is viewed or edited later, exactly the same fields are present as when “create” was used. The advantage of the scheme is that you only need one screen!

  2. Screen Scheme for Bug: Bug, for example, has only five fields in “create” that you can/must fill in. This is because the person reporting the bug usually doesn’t know very much about it. It may be that he or she is having trouble logging in. Now she can report that an error exists, but there is no knowledge about a known global error (like various IDs or the exact reason). That’s why there is a separate, minimalistic screen for creating a bug. If the bug is edited later, the editor may have 50 or more fields to choose from in the “view” and “edit” mode. Here, more detailed information like the description, the status and the exact reason can be recorded. However, these fields are no longer relevant for the person who created the notification. Separating the error message from its resolution speeds up the resolution process immensely.

Attention: You always have “create”, “edit” and “view” to choose from. You alone decide whether there are one, two or three different screens (per task type).

Workflow Scheme

Finally, our graphic shows the configuration of the workflow and its scheme. A workflow defines the sequence of steps that can be taken in a project. Often these steps are: to do → in progress → feedback → done.

The associated scheme places these defined assignments on an assigned issue.

As a Jira administrator, you can link task types with different workflows within a scheme and later apply them to other projects.

Extra tip: All workflows are inactive before they are assigned to a workflow scheme.


A project now takes these schemes (like shoeboxes) and involves all configurations. By having Jira schemes configured, a project gets its specific settings and can be applied to the exact needs of your company or even a single department.

This is why you should use Jira Schemes

If you are a Jira administrator and are bothered by configuration conflicts of your projects and are looking for a quick and efficient solution, Jira schemes are the right tool for you.

Advantages of Jira schemes

  • Enormous time savings

  • Easy reuse of complex rules

  • Unified workflow

  • One change, many impacts: Apply to multiple screens and projects

  • Uncomplicated administration

  • Finally, full transparency in your overview

This graphic shows how clearly structured your administration view can be. The schemes are listed and can be configured by you with a few clicks — the changes take effect directly for all assigned projects!


Jira schemes are based on the useful recycling idea: once significant settings have been made, they can be reused again and again. This saves time and also makes it easier to modify settings for multiple projects later.


Pramodh M
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
December 22, 2021

Wow, Great Article @Andreas Springer _Actonic_!!

Like # people like this
Mykenna Cepek
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
December 22, 2021

Thanks for this overview and some helpful graphics, @Andreas Springer _Actonic_. This can be very helpful to newer admins.

A few more tips:

  • When creating a project, the little "Share settings with an existing project" checkbox very much relates to this topic! Check that checkbox to reuse schemes being used by another project. This avoids creating a whole new set of schemes and related things for that new project.
  • It can help to keep track of abandoned schemes and related things as you're configuring projects. At the time you may know, for example, that you are abandoning a specific scheme or configuration set, and that it can be deleted with confidence. Many Jira instances (and admins) suffer from a big pile of unused configuration accumulated over time. It's hard to find the time for an unglamorous and tedious big cleanup effort.
  • Encouraging your teams to have similar project configurations, when feasible, also helps reduce the complexity for Company-Managed Project configuration. To sell this approach to leaders and teams, point out the reduced confusion and overhead when people participate in more than one project.
Like # people like this
Matt Doar
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
December 22, 2021

It could be useful to mention the other five Jira schemes with a summary of what they are for?

The other thing about schemes is that naming them well, and adding a link to docs in their description, will help you understand what they are for later on

Like # people like this
Ignacio Pulgar
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
December 23, 2021

Thanks for this article, it is a good starting point for new Jira Admins!

Besides, there is a good understanding about the usefulness of sharing schemes among multiple projects.

Just one thing: Please, review the parts about Field Configuration and Field Configuration Scheme, since there are some misleading phrases.

As a reminder, a Field Configuration consists of one list with all existing fields (native + custom) which especifies whether each of them are:

  • Required or optional
  • Shown or hidden
  • Displayed with custom instructional text or not
  • Rendered in one way or another

One or more Field Configurations will then be associated with the Issue Types used by a given project (or applied to all of them by default) through a Field Configuration Scheme which is set in one or more projects.

An active Field Configuration belongs to one or more Field Configuration Schemes. An active Field Configuration Scheme belongs to one or more projects.

Thanks again and congratulations for this article!

Like # people like this
Andreas Springer _Actonic_
Marketplace Partner
Marketplace Partners provide apps and integrations available on the Atlassian Marketplace that extend the power of Atlassian products.
January 3, 2022

Thank you all for your great feedback and tips!

Mykenna Cepek
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
January 26, 2022

Please note that this relates only to Company-Managed Projects.

Team-Managed Projects do not use Schemes.

Like # people like this
Dale Fernandes January 27, 2022

Why have you taken away Priority Schemes? We've migrated from Data Centre and soon will be migrating another Cloud instance into our core 'enterprise' site. The source site was configured a long time ago, and their Priority setup differs to our enterprise site. The migration tooling doesn't help merging priorities it just imports them on top of the existing ones. Priority Schemes would've prevented this.

Really would like to know what the reason for taking that away when everything else (workflow, issue types, screens, field configuration, permissions) has schemes available?

OWen Yang November 4, 2022

I'm just a regular device user who know nothing of internet.  I'm just worry and following up. Seems kinda serious

Rene C_ _Atlassian Cloud Support_
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
August 14, 2023

Hi @Dale Fernandes I know it's been a while since your question but I thought it was important to clarify: Priority schemes where not removed in Jira Cloud, until some time ago they were not part of Server or Cloud, and then they were implemented in Jira Server/Data center. Jira Cloud does not yet have this feature, but there is a feature request and there is active progress, as well as an early access program, you can see more about it here:


Log in or Sign up to comment
AUG Leaders

Atlassian Community Events