Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

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.

Project

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!

Conclusion

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.

5 comments

Pramodh M Community Leader Dec 22, 2021

Wow, Great Article @Andreas Springer _Actonic_!!

Mykenna Cepek Community Leader Dec 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 Ignacio Pulgar likes this

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

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

Thank you all for your great feedback and tips!

Comment

Log in or Sign up to comment
TAGS

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you