Does your Jira application have twelve pages of project screens? That’s probably ten pages too many! New screens and schemes are created each time a new Jira project is created from built-in project templates. You can tell the settings in the screenshot were created by Jira because their names begin with a project key and a colon. Example: CUST: Kanban Default Issue Screen.

‍

‍

Jira default screens often contain more fields than you need. Instead of always using the default screens, I recommend creating custom screens so you have your own Jira issue templates to reuse. Using your own templates reduces the total screens, simplifies the fields presented to users, and ensures consistency between Jira projects.

Good to Know

This article will focus on screens, but the same concept applies to other Jira settings. I frequently build my own custom templates for issue-type schemes, permission schemes, notification schemes, etc.

Additionally, this information applies to Jira Data Center and company-managed projects in Jira Cloud. Team-managed projects in Jira Cloud are schemeless, meaning they do not share settings between projects.

‍

Field Analysis

Before we build anything new, let’s examine the default fields on an issue’s create screen in a Jira Work Management project in Cloud. Understanding what already exists before customizing or adding additional elements is important.

As an example, I’ll choose a built-in project template called “Blank project.”

‍

‍

Here’s the default create screen from the built-in “Blank project” template. The screen contains 13 fields: Summary, Issue Type, Security Level, Attachment, Due date, Description, Reporter, Assignee, Priority, Labels, Time tracking, Start date, and Category. That’s a lot of information to ask a user to provide, especially if not all fields always apply. I recommend reviewing all the fields on your application’s create screens and removing any that aren’t absolutely necessary for issue creation.

For example:

• Does the project have an issue security scheme? If not, there’s no need to load the “Security Level” field and the background logic powering it.
  
• Is the “Due Date” and “Start Date” known when the issue is created? Sometimes, that information isn’t determined until later, after an issue has been reviewed for understanding, assigned, scheduled, or prioritized against other issues.
  
• Do users often log issues on behalf of others? If not, consider removing the “Reporter” field from the create screen and show it on the edit/view screen(s) instead.

‍

‍

Recommendation: Simplify the create screen as much as possible so users can quickly submit issues and focus on providing detailed and accurate initial information.

‍

‍

Build a Jira Issue Template

Now that we’ve reviewed an example of fields a built-in Jira project template includes, let’s build our own template for our organization’s needs and reuse it between projects.

For this example, I’ll build for the use case of simple business and “to do” Jira projects. Other use cases, for development or support work for example, should have their own custom templates too.

Build Screens

First, I’ll create a custom screen for the create action. Log in as a Jira application administrator and visit the “Screens” page in the “Issues” admin area. Then, click the “Add Screen” button at the top right.

‍

‍

I’ll name the new screen “Custom default: General create screen.” I specifically chose this naming to separate the screen from Jira’s other built-in settings, also named “default.” Further, the words “general” and “create” explain where and how the screen is used.

Tip: Decide on a common naming format that helps fellow Jira administrators understand the purpose of schemes and settings.

‍

‍

Add Fields to Screens

Next, add a small number of fields for the information that needs to be collected immediately. I’ll add Summary, Components, Priority, Description, Attachment, Labels, Linked Issues, and Parent. Here is what each field does, why I selected it, and any related tips.

Summary

This field holds the issue’s “title” and is required by Jira. Encourage users to provide meaningful, keyword-rich information that conveys purpose and helps them find the issue again later.

Components

A component is a way to categorize issues. If a component is selected, an issue can automatically be assigned to a specific person. Auto-assignment only occurs on the create action however. Selecting a component later, on a different edit or view screen does not change the assignee.

Tip: If using “Components” for auto-assignment, there’s no need to show the “Assignee” field on the create screen. If you do, and the user chooses an assignee, any component-specific auto-assignment settings are ignored.

Priority

It’s useful to collect the requestor’s perception of priority, but do consider that it may differ from reality. For example, the reporter needs the work done yesterday, but the team can’t actually accommodate it until next week. This field’s initial value often changes after a prioritization or estimation discussion.

Tip: If collecting a “Priority” and a “Due Date,” I like to display the “Priority” field first. If the requestor determines the relative priority first, they may enter a more realistic requested date.

Description

This field holds the issue’s details. If users aren't providing this information, consider making it required in the project’s field configuration. You may also need to suggest what level of detail to provide.

Tip: Use a field configuration to provide the user with helpful field descriptions and reminders. Alternatively, provide user training or documentation outside of Jira.

‍

‍

Note: The above field description is just a Jira functionality example. A highly specific definition like this wouldn’t likely be part of a general template used by multiple Jira projects.

Attachment

This field is used for additional non-text information like screenshots, forms, diagrams, etc. When necessary, it is best used as an addendum to the description. Don’t require this field unless a file is needed for every use case.

Labels

Labels are keywords or phrases like hashtags (without the “#” sign). Use this field as an additional way to classify issues or find them later. Users can query for issues, including or excluding a specific label. Separate multiple words with dashes in the following format: keyword1-keyword2-keyword3.

Tip: Encourage users to leverage this field for additional information that hasn’t already been collected elsewhere. For example, don’t duplicate the information selected in the “Component” field.

Linked Issues

Use this field to link the new Jira issue to any other issue. This is useful for associating related, duplicate, or dependent issues together — even if the issues are of different types or in different projects. For example, Link the bug in the development Jira project that fixes the customer’s problem reported in the support Jira project. Users can query for issues linked to other issues. Users often forget to link related issues, so I like to ask for this information early.

Parent or Epic Link

The “Parent” field in Jira Cloud or the “Epic Link” field in Jira Data Center creates a parent/child relationship between issues. Just like remembering to link related issues, users often forget to associate child issues with the parent they support. Asking for this information early may improve adoption.

Build Additional Screens and Schemes

In addition to a custom create screen, I also build a custom edit and/or view screen.

Good to Know

Jira Data Center has a screen for viewing an issue and a different screen for editing issue information. You can build a separate screen for each action or share the same screen for both editing and viewing.

In Jira Cloud, fields are edited inline, meaning a user simply clicks a field and changes its value without loading a new page or overlay. As such, there’s no need for a separate screen for editing. I often name the screen “edit/view.”

The edit/view (or separate edit and view screens) should contain all the fields on the create screen, plus any additional standard or custom fields that apply to the template’s use case.

In the example, I’ve copied the custom create screen and named it Custom default: General edit/view screen. Then, I added any additional fields needed for most business-type Jira projects, such as Due Date, Assignee, Reporter, Time Tracking, and Log Work.

‍

‍

Finally, I built the required screen scheme and issue-type screen scheme to connect the custom screens.

Here’s the full Jira issue screen template I built for general business and “to-do” projects. The screen scheme has one screen for the create action and a second screen shared by the edit and view actions. Depending on your needs, a screen scheme can have one, two, or three custom screens.

‍

‍

‍

Apply a Jira Issue Template

Once the template screens and schemes are built, there are two ways to apply them.

For Existing Jira Projects

To associate the custom screens with a Jira project, visit the “Summary” page in a project’s settings area. Scroll down to the “Screens” section and click the name of the issue type screen scheme.

‍

‍

On the project’s issue type screen scheme page, click the “Actions” button on the top right. Then click the “Use a different scheme” option to change to the custom scheme.

‍

‍

For New Jira Projects

In the new Jira project creation wizard, check the box labeled “Share settings with an existing project.” Then, select an existing project that uses the desired screens.

‍

‍

Note: The “share settings” capability applies to projects in Jira Data Center and company-managed projects in Jira Cloud. Team-managed projects in Jira Cloud are schemeless. Also, this capability is not available in the Jira Cloud Free plan. Upgrade to the Standard, Premium, or Enterprise plan to leverage it.

Tip: As shown in the screenshot, I like to build a template Jira project that uses all my custom template settings. I use this template project to maintain and test all the shared custom schemes.

‍

‍

Final Result

Now, the custom settings are applied to the Jira project. Remember to view the screens from an end user’s perspective to make sure they look and function as intended. Here’s the custom create screen with its eight initial fields.

‍

‍

Here’s the custom edit/view screen with its initial and additional fields.

‍

‍

Activities to Try

Now it’s your turn!  Build a custom issue type screen scheme, screen scheme(s), and screen(s) for a common use case in your organization.

Ideas

• Build a template for development-type projects
• Build a template for support-type or Jira Service Management projects
• Build a template for other common use cases like consulting, long-term initiatives, customers, external vendors, etc.

Next time you create a new Jira project, use your custom templates instead of the default settings.

Resources

• Configure issue screens — https://support.atlassian.com/jira-cloud-administration/docs/configure-issue-screens/ 
• Manage screen schemes — https://support.atlassian.com/jira-cloud-administration/docs/manage-screen-schemes/ 
• Manage issue type screens — https://support.atlassian.com/jira-cloud-administration/docs/manage-issue-type-screens/ 

‍