I’d like to make one field dependent on the data in another field. How do I do that in Jira?
Answer
Basic Example
Types of selection fields
In addition to single or multi-select lists, Jira also a cascading selection type.
The cascading field type has two drop down menus. The options in the second menu are determined by the selection in the first menu.
This field works well for grouping work by two levels like category and sub-category. Sometimes this field is useful and other times, two separate fields are used instead. It all depends on whether one selection must be dependent on another and your reporting needs.
Here’s another view of the same cascading field from the example above. This how it looks when you edit it in Cloud. The first selection is on the top and the second selection is on the bottom.
REPORTING
I find cascading select fields hard for end users to query. The JQL for this field type is a little daunting. Here’s the format to use and an example in Cloud.
JQL format: customfield in cascadeOption(parentOption,childOption)
JQL example: “Operational categorization[Select List (cascading)]” in cascadeOption(“Server Change”,”Storage”)
Use this to query the standard field called “Operational categorization” in Jira Service Management.
Advanced Example
Another method to limit selections is using the Jira Miscellaneous Workflow Extensions app from the Atlassian Marketplace. Here’s an advanced use case I built for one of my Jira Server clients.
The client wanted to better classify the type of support they provide for internal applications. They wanted to limit the selections in a drop-down field based on component selection.
For example, if the component is “Microsoft Excel” allow “Functional” and “Technical” as support selections but not “Security”. In the screenshot, “Security” was selected, so an error message is displayed at the top of the overlay.
Custom scripted workflow validator
This was easy to do with Jira Miscellaneous Workflow Extensions. I added a “Build your own” scripted validator, to a workflow transition, and used a little bit of code to limit the custom field selections.
For additional help with fields and related topics, take my Jira: Advanced Administration course on LinkedIn Learning.
Have a Question?
Use the “Ask a Question” form on the top right and we’ll answer it in a future post.
We are using a shared screen scheme across multiple projects. How do we make changes to one project without impacting others?
Answer
It’s great that multiple projects share schemes! Sharing schemes is the goal. Whether it’s screens, issue types, workflows, or other settings, Jira maintenance is easiest when schemes are shared. But sometimes, there’s a business need for one project’s settings to differ from the rest. In this situation, the answer is to create new schemes and associate them with a specific project. Now you can customize that project without impacting other projects.
About Schemes
Admin > Issues > Screens administration page
First, let’s discuss schemes in general. A scheme is a configuration or collection of settings. There are schemes for issue types, workflows, screens, fields, priorities, issue security, notifications, and permissions. In this post, we’ll tackle the most confusing Jira configuration area. We’ll explore the screens, screen schemes, and issue type screen schemes pages in the administration area.
Screen Settings
Note: Schemes apply to Jira Server, Jira Data Center, and “Classic” projects in Jira Cloud. “Next-gen” projects in Jira Cloud are schemeless.
Screens
Two Jira Screens with Different Fields
Screens define which fields are present and their display order. In the example, one screen has the “Story Points” standard field and the other screen has the “Steps to Reproduce” custom field.
Screen schemes
One Screen for All Actions
Screen schemes associate screens with the three issue actions: create, edit, and view. In the example, there’s one screen for all actions but a screen scheme can have 1, 2, or 3 total screens.
It’s a best practice to limit the number of fields on the create screen and only show fields the reporter can complete. Since an issue’s reporter doesn’t usually schedule work, omit fields like “Fix Version” and “Due Date” on the create screen. Show these fields on the edit and view screens instead. Screen schemes make it possible to show different fields for different actions.
Issue type screen schemes
Simple Example: One Screen Scheme for all Issue Types and one Screen for all Actions
This scheme associates screen schemes with different issue types. In the example, there’s one screen scheme shared by the Story and Bug issue types. A project can have one screen scheme per issue type or fewer schemes. Fewer schemes are always easier to maintain.
Alternatively, you can have different screens for each issue type. For example, the Bug screen scheme may contain a screen with fields like “Steps to Reproduce” and “Expected Result”.
Regardless of the number of screen schemes and screens, a project can only have one issue type screen scheme.
Common Example
Here’s a more complex but common example.
In the example:
The issue type screen scheme contains two screen schemes.
The first screen scheme at the top is for the Story issue type.
It has one screen for all issue actions and contains three fields.
The second screen scheme at the bottom is for the Bug issue type.
It has two screens.
The first screen at the top is for the create action and contains three fields.
The second screen at the bottom is for the edit and view actions and contains four fields.
How to Decouple a Project
Here’s the simple scheme relationship example again. There’s one screen scheme for all issue types and one screen for all actions. This means all issues have the same fields.
Let’s imagine, all projects share these settings but we want to add a custom field to only one project. Here are the steps to create the needed schemes and decuple a Jira project.
Create a new screen or copy an existing one
Add the custom field to the new screen
Create a new screen scheme or copy an existing one
Associate the new screen with the new screen scheme
Create a new issue type screen scheme or copy an existing one
Associate the new screen scheme with the issue type screen scheme
At this point, we’ve created new schemes, but they are unused and don’t impact any Jira projects or issues. The last step is to associate a project with the new issue type screen scheme. This change does impact Jira data.
Go to the Jira project to modify and click the “Project Settings” link in the left sidebar
Click the “Screens” link in the left sidebar
At the top right, click the “Actions” button and select “Use a different scheme”
Choose the new issue type screen scheme and click the form submission button
Finally, check your work by verifying the new field displays when creating or editing issues in the updated Jira project.
Huh?
Still confused? Don’t worry! This was the hardest part of Jira administration for me to understand. It will make more sense after you’ve practiced these types of changes in the application. Use your Jira test environment to experiment with these settings until they make more sense. Once you understand all the screen settings, the other scheme relationships (ex: workflows) will make more sense too.
How does Jira ordering work? What happens when users prioritize issues differently or on different boards? How do I know if ordering is functioning correctly?
Answer
Jira provides a way to order and prioritize issues. On a board, simply drag an issue above or below another issue to determine ranking.
Ranking is a global concept. Issues are ranked against other issues regardless of their Jira project, issue type, or associated board. Ranking is not related to other standard fields like “Original Estimate”, “Story Points” or “Priority” but you can use these concepts together to influence your prioritization process.
An issue only has one rank even if it’s included in multiple boards. The display order is based on an issue’s relation to other issues on the board.
If you change an issue’s ranking on one board, the ranking changes automatically on other boards. Project Managers, Team Leads, and Product Owners need to work together to determine overall strategic priorities.
More about Ranking
Before a sophisticated ranking system was available in Jira, we all created a static, custom number field to track order. This was tedious to maintain. When priority changed, we had to manually renumber the values in the custom field. This was especially problematic for long issue lists.
Luckily, today, there’s a better method. Today’s system is called LexoRank and it uses numbers and letters for maximum ordering flexibility. An issue’s order is stored, as a string, in single field called “Rank”. Jira Administrators can see the field on the “Custom Fields” page, but it is “locked” and not editable. Admins might also see remnants of old ranking fields marked “obsolete” too.
Order by Rank with JQL
In addition to viewing issue rank on boards, you can also order issues by rank with JQL. This is useful for filters and dashboards. To see issues in one project, ranked from highest to lowest, use a query like: project = project-name ORDER BY Rank ASC
Troubleshooting
Jira periodically rebalances or “recalculates” issue order. The application checks for and handles rebalancing automatically, as a background service. It detects problems like missing minimum or maximum values, strings that are too long, or duplicate ranks in the database. Jira administrators can see the rebalancing status and check for integrity problems from the following page: Admin > System > LexoRank management.
Jira Server LexoRank management page
Here’s a screenshot of the LexoRank management page in Jira Server. (The page looks similar in Jira Cloud.)
The middle of the page shows information about the ranking field and its status. In the example, there are 188 ranked issues and the rank status is “OK”.
You can manually trigger a rebalance by clicking the “Balance all fields” button or the “Balance field” link. To check ranking integrity, click the “Run integrity checks” button (not pictured) at the bottom of the screen. You can perform these actions without impacting Jira’s availability.
Resources
Use these additional resources to learn more about ranking.
When I started using Jira in 2011 there was only one type. But now there are different application types, like Jira Work Management or Core, Jira Software, Jira Service Management, and Jira Product Discovery and different deployment types, like Cloud, Server, and Data Center. If you have Jira Cloud, there are also different plans like Free, Standard, Premium, and Enterprise. How do you know which you have? Why does it matter?
Answer
In an ideal world, you wouldn’t need to know which type of Jira you have. But because the types have different features, abilities, user interfaces, apps, documentation, and terminology, its helpful to know which you’re using.
Here’s how to determine which Jira application type, deployment type, and plan you have.
Step 1: Determine the Deployment Type
There are three Jira deployment types: Cloud, Server, and Data Center. The different types have different features and capabilities.
If you have Jira Cloud, Atlassian hosts the application on their servers and they are responsible for upgrades, email, and up-time.
If you have Jira Server, your organization hosts the application in a physical location (like a server room) or in a virtual environment (like on Amazon’s web servers). Your Systems team is responsible for upgrades and all maintenance activities. Note: Atlassian stopped selling new licenses of Server products in February 2021 and support ended in February 2024.
Jira Data Center is for mission-critical environments. Like Server, your organization hosts the application but there are multiple application instances. If one instance goes down, the others ensure Jira remains available.
There are a few ways to determine which type you have.
First, look at the URL format in the browser’s address bar. If the format is “yourcompany.atlassian.net”, Atlassian is hosting Jira. Atlassian has future plans for custom URLs, but for now, it’s a quick way to to signify you have Jira Cloud.
Next, both Jira Server and Data Center have the version number displayed at the bottom of most pages. You can also see the version number on the Help > About Jira page in the main navigation. You’ll need this version number to leverage the correct documentation.
Footer in Jira Server and Data Center
Step 2: Determine the Application Type
There are multiple Jira application types: All have the same look and feel but different uses and abilities. The applications are used separately or together.
Jira Work Management (Cloud) and Jira Core (Server and Data Center) contains all the main Jira features like Jira projects, issues, workflows, and users. This type is best for business teams and for managing initiatives, processes, and tasks.
Jira Software is designed for development teams and teams using a Scrum or Kanban methodology. It includes dev-specific features like sprints, story points, backlogs, and integration with tools like Bamboo and Bitbucket.
Jira Service Management is built for help and support teams of all kinds. For example, the HR team can collect benefits questions and reimbursement requests, the Facilities team can receive requests for new desks and chairs, and the Legal team can process contract review requests. It contains additional features like SLAs (service level agreements), queues for grouping requests based on type and severity, and additional reporting for workload and customer satisfaction. JSM has a simple request entry interface called the “Customer Portal”. It also integrates with Confluence to display self service help articles.
Jira Product Discovery (Cloud) helps product and pipeline owners collect ideas, assess and prioritize them, and track them through delivery.
Jira Project Types
It’s hard for end users to determine the application type. Users can get insight from the “Projects” page however. Click the “Projects” link in the main navigation and select “View all projects”.
Next, look in column labeled “Type”. Your application may have one or more types at the same time. For example, you may only have access to business projects but your colleague may also has access to software projects.
Jira Cloud Project Types
Jira Server and Data Center Project Types
For Jira Administrators
Application admins can also find additional product details by logging into my.atlassian.com to view your bill. Here’s an example bill from Cloud and Server.
Sample Cloud BillSample Server Bill
Step 3: Determine the Plan Type (Cloud only)
For Jira Administrators
Finally, Atlassian offers multiple Jira Cloud plans: Free, Standard, Premium, and Enterprise. The differences between the plans are detailed here.
Application admins can view the plan by visiting admin.atlassian.com or by clicking Admin > Billing in Jira. The screenshot example shows the “Standard” plan for Jira Software.
Atlassian Standard Plan
Still not sure which Jira you have?Ask us, your Jira Administrator, or Atlassian for help.
Why does it matter?
First, you need to know which set of documentation to reference. The screenshot shows there’s different documentation for Cloud and for each Server and Data Center version.
Server and Data Center Documentation
Don’t make my mistake and waste time reading the wrong information!
Second, you can extend Jira’s capabilities with apps from the Atlassian Marketplace. The screenshot shows this add-on is available for all three hosting options. That’s not true for every app, however.
App for Multiple Deployment Types
Always make sure that an app is available for your application type, deployment type, and version.
Have a Question?
Use the “Ask a Question” form on the top right and we’ll answer it in a future post.
What is the difference between an Epic, Story, Task, and other issue types? Which Issue Types are standard and which are custom? Which issues types are added by Jira Service Desk?
Answer
An Issue Type is a way issues are classified in a Jira project. There are standard types that come with Jira and additional custom types.
Standard Issue Types
Jira Software comes with five standard issue types so issues can have different fields, different workflows, or both, within the same Jira project. For example, a Bug issue type might have defect-specific fields like “Steps to Reproduce” and “Expected Result.” Those two fields don’t belong on a screen for the Task issue type however.
Tip: I recommend every Jira project start off with Epic, Task, and Sub-task, regardless of the type of work tracked. Add additional standard and custom types when there’s a measurable business need.
Issue Type
Atlassian’s Definition
Rachel’s Notes
Example Issue Summary (Title)
Task
Task that needs to be done
This is your generic “catch all” type. Use it for any type of work not represented by the other available types.Tip: Creating specifically named tasks (Ex: Security Task, Marketing Task, etc.) is not recommended.
Bake a cake
Sub-task
Smaller task within a larger piece of work
The smallest piece of work required to complete a larger piece of work. Often used to assign parts of a larger task to different team members.
Mix cake ingredients
Epic
Large piece of work that encompasses many issues
A term from “Agile” methodology but useful to any type of team, regardless of methodology.Tip: Link other issues to the Epic they support.
Make deserts for bake sale
Story
Functionality request expressed from the perspective of the user
AKA: “User Story” or other form of development request. Often used by software development teams to encompass requirements, features, or enhancements. Sometimes written in the format: As a <type of user>, I want <some goal> so that <some reason>.
As a bake sale attendee, I would like to eat brownies because I’m allergic to cakeOR
Make brownies for bake sale
Bug
Problem that impairs product or service functionality
Often used to track problems, errors, omissions, defects, or “things to fix”.
Cake is burnt
Additionally, Jira Service Desk adds four more standard types for support projects.
Issue Type
Atlassian’s Definition
Example Issue Summary (Title)
Incident
System outage or incident
The kitchen caught fire yesterday
Service request
General request from a user for a product or service
Fix microwave damaged during kitchen fire
Change
Rollout of new technologies or solutions
Change the gas stove to an electric hot plate
Problem
Track underlying causes of incidents
The electric hot plate doesn’t get hot enoughOR
Train users on gas stove safety
Custom Issue Types
You may have additional custom types in your project’s selection list. These were either added by Jira administrators, by additional Jira functions, or by third party apps and add-ons.
For example, a Legal Jira project may have custom issue types like: Agreement or Contract. A Marketing Jira project may have: Campaign, Creative, or Design. A few custom issue types are expected, but Jira administrators should keep the list of choices as short as possible.
What is a Jira issue and a Jira project? Why are users often confused by these terms? Why are things named the way they are?
Answer
Jira terminology is strange at first and even foreign if you’re using Jira to track business processes. Jira began as a bug tracking tool for software development teams and morphed into an issue tracker and project management tool for all teams. Some of the naming reflects its origins and the need for somewhat generic terminology so it can support #allthethings. Further, your organization may have introduced additional custom naming or language translations, which can add to the confusion.
Here are three fundamental Jira terminology concepts to understand:
Issue – an individual item in Jira
Why the confusion? The dictionary defines “issue” as “an important topic or problem for debate or discussion”. In Jira however, an “issue” represents all types of requests including: things to do, tasks, bugs and defects, new features, improvements, changes, incidents, tickets, problems, etc. An issue is a single unique record of any type, regardless of its content or the scenario. Requests like “I need a new desk phone” is an issue just like “Create a new product” and “The server is down!” are issues. Each Jira issue has a unique key in the format: KEY-123.
Project – a collection of Jira issues
Why the confusion? Teams have their own internal initiatives or strategic priorities they often call “projects.” Yet in Jira, a collection of issues is also called a project! For example, the Marketing team’s many internal projects are tracked in their one Jira project. Think of a Jira project is a bucket that contains a “to do” list. Projects are often set up per department, per team, or to track large initiatives with a known end date.
Issue Type – a classification of issues in a Jira project
Why the confusion? Each Jira issue can be of a different type. For example, you may use a “Bug” type to report a defect and a “Feature” type to request new functionality. Each Jira project can have its own set of available issue types. A development project may have issue types like: Feature and Bug and a Legal project may have issue types like: Task and Sub-task. Different issue types allow for different fields, different workflows, or both, within the same Jira project.
Not sure which issue type to select? Just make your best guess. An issue can easily be changed later using Jira’s “Move” command.
Regardless of the wording, you can use Jira to: schedule and record work, manage your project pipeline, report and fix bugs, triage issues, report time and monitor progress, track changes and tasks, and keep a authoritative, historical, and legal record of work.
Have a Question?
Use the “Ask a Question” form on the top right and we’ll answer it in a future post.
