Fields, Screens and Schemes - Oh My! ACP-420 Jira Service Projects #6
Schemes! I definitely tripped over my own tongue with this one... Issue type screen scheme is way too hard to say.
Beyond not being able to say them properly I personally find them incredibly confusing! Mainly this is because I have been a Jira admin before... This means my hands on skills are lacking. I picked up small amount here's and there as I worked with the Jira admins though, and event that little bit was incredibly useful. Even just understanding that schemes are a thing is helpful as it makes it easier to talk to someone else about updating the system.
That said, this means is I need to dedicate more time to studying this part of the exam than I do for others (check out the new acp-420 page for some things I'm doing to drill this in). I’ll also be spending some time mapping out how all these schemes relate to each other. I find that visually drawing things helps my mind keep them separate.
Schemes and Fields, Oh My!
Schemes, however, are very important for us to understand as they are the shared configurations in Jira. They allow us as admins to create specific settings and then apply them across projects. For example all of our support projects could share the same issue types, workflows, screens and fields. Then, when we need to update them we just update it nice and it applies everywhere.
Fields, while not a scheme, are where a lot of this starts. After all, when I think of Jira I immediately think of all the information I need to fill out. One thing to remember is that fields aren't directly applied to projects or issue types. Instead they're grouped into screens. These screens are then added to a screen scheme which can be applied across projects.
There’s also two flavours of fields:
System Fields - these are default in Jira and tend to be critical. Things like Summary, Description and Key fall into this bucket
Custom fields - These are fields you create
Most of the settings we’ll cover here show up under “Issues” under the Settings menu:
Schemes for projects
There's seven total schemes that impact projects, with issue type security schemes being optional. Each of these let us control different aspects of the project.
-
Notification schemes allow you to define what notifications are sent out when and to who.
-
Priority schemes allow projects to have a different list of priorities. While this doesn’t seem like much it can have a huge impact on end users!
Personally I find a lot of folks frustrated at having to use the same list of priorities as everyone else (it also tends to get long… and repetitive…). This scheme lets you break out different lists of priorities for different projects.
It also applies to Team-managed projects!
-
These allow you to associate screens with an issue operation (e.g. view/edit/create). Basically they tell Jira which screen to use for those actions.
For example, you might have one specific screen displayed when creating bugs, but a different one available when editing bugs.
-
This defines what permissions are provided to what individuals, groups or roles in a project. Setting this up helps ensure that similar projects get similar permissions, making a project admin’s job a lot easier.
While the project admin can’t directly edit permissions they can assign roles, so ensure this is setup to support them!
-
This scheme defines the issue types available to a project.
For example your Project Management projects could have Epic/Story/Subtask while your Support projects get Bug/Incident/Request.
-
This scheme connects your field configurations (how a specific field behaves, e.g. hidden, required etc) to a specific issue type.
For example the “priority” field could be hidden on Bug tickets by default, but displayed on Project tickets.
Schemes for Issues
Three schemes apply directly to issues. These allow us to control things like the workflow specific issue types fulfill.
-
This scheme ties fields you’ve created to specific issue types. For example, you may have a “Symptom” field. In order to make it available to an issue you first have to add it to a Field Config scheme, and then tie that scheme to the issue type.
-
This scheme controls the workflow a given issue type uses. For example, the Bug issue type may have a specific set of statuses it moves through, while the Story issue type has a completely different set.
This workflow allows you to standardize the flow of specific issue types across projects.
-
While the Screen Scheme associates screens with operations, the Issue Type Screen scheme associates them with issue types.
For example you might have a Screen Scheme that contains specific fields for “Create” and then apply that to specific issue types via an Issue Type Screen Scheme. A different Issue Type Screen Scheme could apply different “Create” screens to other issue types.
But what about Project Admins?
Jira admins don't get to have all the fun though. Project admins can control the request screens by adding, removing, and managing fields that appear on request Types with is issue layout. This allows each project to choose what order fields are displayed in, what name is display to the customer and some other options. Giving this local control to project admins makes it much easier for them to handle day to day requests to improve their project.. although they still need to work with a Jira admin to add fields, change workflows and the like.
Each screen scheme gets one layout (which the project admin can manage) per project (something we need to keep in mind as Jira admins!). Project admins will be able to modify the “view” screen by adding, removing and reordering existing fields (but they can’t create new ones). Project admins can also hide empty fields, which can help clean things up for teams that don’t need every field in their project.
There is an important note in Atlassian’s training “Project admins can only add fields that exist in their project’s View screen configuration. If they remove a field from the issue layout, the field still exists in the View screen configuration. It just isn’t visible for that particular project.”
FAQ
What is a good way to name my schemes?
It can get confusing quickly! There’s some different ways, but folks typcially rename the default to something like . Project key - type — example : ABC-SS for the ABC project Screen Scheme
How do I change priorities??
There is a Priority Scheme that allows you to change priorities based on the scheme used.
What is the new name for “issue”?
Work item… although I bet I’ll still call it “issue” for a while…
