Jira schemas are a complex and sometimes difficult to understand area of responsibility. And not only for new Jira administrators, but also for Atlassian veterans. It is not uncommon for a Jira admin to have to laboriously work their way through many different schemas when a customization is required. With larger and historically grown systems, there can even be hundreds of schemas.
Here is an example of a worst-case scenario.
However, configuring and adapting schemas is a central part of a Jira admin's daily tasks. In this blog, we shed some light on the subject and explain what schemas there are, how they interact and how you can put a stop to schema chaos in the long term.
What are Jira schemas?
Schemas are a way of standardizing the configuration of different Jira components for multiple projects. Elementary components of a Jira project, such as the status (transitions) of a workflow, the available task types and displayed screens, can be configured with schemas.
You can configure the following schemas in Jira:
- Task type schema
- Workflow schema
- Screen template schema
- Screen template schema for task types
- Field configuration schema
- Notification schema
- Authorization schema
You assign one of the above schemes to each Jira project. You then configure yourself which associated component is displayed in which case. For example, the screen template schema allows you to define which screens Jira displays when creating, editing and displaying tasks. For example, the software can only request a single relevant mandatory field during the creation of a task and only complete all other fields during subsequent processing in the workflow.
By default, Jira always creates a new project-specific task type schema, workflow schema, screen template schema and screen template schema for task types when a project is created and assigns this to the project. The standard schema, which is available out-of-the-box, is automatically used for the other possible schemas. However, it is also possible to share the above four project-specific schemas with another project during creation.
Important note: If you create a new project, you can reuse existing schemas from an existing project. However, this has the disadvantage that changes to shared schemas are inherited in all affected projects. If you want to prevent this in certain projects, you have to create individual schemas there.
How do Jira schemas interact?
All Jira schemas are closely interlinked and combine to determine what kind of process is displayed and what actions are possible - for example field changes, workflow steps, comments, etc.
Let's take a look at the whole thing using an example process and work our way through it step by step: First, we create a process. The first effects of a schema are also immediately visible in the creation screen. The fields displayed here in the creation mask are recorded in a screen mask. Jira assigns this screen template in the screen template schema for the "Standard" task function. This means that the same screen template is used when creating, editing and viewing the task.
From the screen template level, the next level up is the screen template for task types. Here, the user determines which screen template is used depending on the task type. This means that bugs and stories can be displayed in different screens. Only the screen template for task types is assigned to the project. The other schemas mentioned here are accessed implicitly via the screen template schema for issue types.
New Jira issue - ready for use
We have now created our issue, filled it with content and are ready to work with it. But now we notice: Technical editors often don't maintain the component field at all! As a result, Scrum Masters often assign some processes to the wrong developer. We can prevent this mistake with the field configuration schema. In the field configuration schema, individual field configurations can be assigned to an activity type. In the field configuration itself, you can hide fields completely, label them differently depending on the project and mark them as mandatory fields. Here too, only the field configuration schema is assigned to a project and thus implicitly accesses the activity type-dependent field configurations.
Our project is now prepared for the future and there should be no misunderstandings regarding incorrect components. Now the developers can get started and run the process through the workflow. Which workflow steps are possible depends on the workflow schema set in the project. Workflow schemas regulate, you can almost imagine, which workflow is used for which type of process. This means that stories and bugs can run through two separate workflows in the same project.
As you may have noticed, almost all of the schemas discussed so far are related to task types in some way. We will therefore briefly discuss the last type of schema that is automatically generated during project creation: the task type schema. Any number of task types can be assigned to this. A task type schema is then linked to a project. In the project, it is then only possible to create the task types defined in the task type schema.
The two most important Jira schemas
Last but not least, we have two important schemas: the authorization schema and the notification schema. Both are not linked to task types, but to people. Authorization schemas control who can perform activities such as "assign tasks", "add comments" or "manage sprints" in a project. Notification schemes, on the other hand, determine who receives an email notification for such activities. However, both types of schema have one thing in common: the schemas can be generalized in such a way that they can be used globally for all projects and you can still individualize them per project!
The power lies in the diverse assignment options that are possible for the two schemas. For example, the currently assigned user of an activity, members of a specific project role, the activity author or even users from user-defined fields can be used dynamically. This could be used to solve the following scenario, for example:
- always notify the assigned user of new comments and changes to the task itself
- only the currently assigned user can move tasks forward in the workflow
- upon completion of a task à notify the project manager, author and a user-defined contact by e-mail
- Members of the "Stakeholder" project role can assign tasks, but only members of the "Developer" project role can be assigned these tasks
Best practices: reusable project structures
If possible, you should always handle projects using the same process. This approach must also be followed outside of Jira (in actual project management). This means, for example, that you carry out development projects agilely according to Scrum or classically according to the waterfall model. Projects should not contain a mixture of both methods or deviate greatly from the standard. This allows the Jira administrator to create a few generally valid schemes that the participants can then apply to all projects.
In practice, it is often the case that although many different projects have been created with similar schemas, they have not been consolidated. A typical case of "historically grown". However, consolidation is not easy, as you always have to coordinate with negative project managers on how the schemas (and therefore also workflows, task types, screen masks and field configurations!) should be structured in the future. Depending on the project, you may also have to reach an individual agreement. Your aim should be to standardize as much as possible. This will make navigation easier and more targeted for both administrators and end users.
In this context, we recommend that you name all schemas and their associated functionality in a standardized way. With countless schemas with a variety of names, it is easy to lose track. Names such as "BM_Scrum_Story" for "screen template schemas", project style "Scrum" and activity type "Story" make it immediately clear what purpose the respective schema serves.
Our last tip works best if you combine it with our first tip in this blog post: Rely on project roles as much as possible. The project administrator manages the project roles themselves and thus enables the greatest possible flexibility without having to involve a Jira administrator. If project roles are used in the generally applicable schemas, the project administrator has a certain degree of autonomy over their project and its members. Scenarios such as project role-dependent notifications (as described above) can therefore be managed by the project administrator themselves without the Jira administrator having to make changes to the schemas or the project.
We hope we have shed some light on the subject. However, if you are still in the dark, simply contact us and we will be happy to help and advise you.
