In this guide, we walk through Jira space configuration basics including work item types, schemes, and workflows, the settings you’ll interact with most as a Jira admin. By understanding how these elements connect, you’ll be able to configure projects cleanly, avoid accidental changes that ripple across multiple spaces, and maintain a streamlined experience for your teams.
This is Part 3 of our Jira Admin Essentials series, where we focus specifically on the project-level settings that control what work looks like and how it flows through your system.
In our video, Marvin, a Technical Support Engineer in DevOps at re:solution GmbH, walks through each of these settings live in a demo instance so you can see exactly where they live and what they control:
Project Settings Overview: Where Day-to-Day Admin Happens
Most of your day-to-day Jira administration will happen inside a space (project). To access these settings, you navigate to your project, click the three dots menu, and select space settings. From the detailed settings panel, you can perform several foundational tasks that every admin should be familiar with.
Here’s what you can manage from the project settings screen:
- Rename the project, Update the display name of your space at any time.
- Find the project key, This is critical for JQL searches, reporting, and any database-level actions you might perform later.
- Set the team type or project category, Helps organize spaces across your organization.
- Change the project owner, Assign ownership to the appropriate person.
- Update the project avatar/icon, A visual identifier that helps users quickly recognize the space.
These are simple but important configurations that set the foundation for everything else in the project.
Work Item Types (Issue Types)
Work item types define what work items look like within a space. Out of the box, Jira provides types like Epic, Story, Task, and Bug. However, you also have the ability to create custom work types tailored to your organization’s needs, for example, a Change Request or a Support Ticket.
To create a new work item type, the fastest method shown in our video is to use the administration panel. Navigate to the work items section, select work types, and click the option to add a new work type. You’ll give it a name, and you can immediately assign it to a work type scheme. The process is straightforward, and it gives you the flexibility to model your Jira instance around how your teams actually work.
Understanding Schemes: Why Projects Don’t All Look the Same
A scheme is one of the most important concepts for Jira admins to understand. In essence, a scheme is a collection of work item types that gets assigned to a space. This means different spaces can display different work item types based on what’s relevant to their team.
For example, a software project can focus on Epics, Stories, and Bugs, while a support project can focus on Incidents and Requests. This separation provides several key benefits:
- Fewer options, Users only see the work item types that are relevant to their space.
- Less confusion, Teams aren’t overwhelmed by types they’ll never use.
- Cleaner reporting, Data is more meaningful when it’s not cluttered with irrelevant item types.
Schemes are also how Jira determines which workflows apply to which issue types within a project. This layered configuration model is what makes Jira so powerful, but it’s also where things can get complex if you’re not careful.
Screens: Controlling What Users See
Screens define which fields appear to users when they create or edit a work item. In our video, we navigate to the screens section within the space settings under request management. You’ll see the screens that have been added by default, as well as any that were configured later for that specific space.
Screens connect into the overall scheme model, meaning they’re part of the broader configuration that determines the user experience at the project level. Understanding where screens are configured helps you control what information is collected and displayed at each stage of a work item’s lifecycle.
Workflows: How Issues Move Through Statuses
The Basics of Workflow Configuration
Workflows define how a work item moves through statuses, typically from To Do, to In Progress, to Done. In our video, Marvin demonstrates this by opening an example workflow and clicking edit workflow, which launches a visual editor.
The workflow editor provides a drag-and-drop UI where you can modify statuses and define transitions between them. You can specify what happens after a status like To Do, or what conditions must be met before a work item can move to Done. This visual approach makes it much easier to design and understand complex workflows.
Different Work Item Types Can Have Different Workflows
One of the key things to understand is that different work item types can follow entirely different workflows within the same space. For instance, a Bug might include extra steps like a quality review stage or a “Ready for Release” status, while a simple Task can follow a minimal To Do → In Progress → Done path. This flexibility allows you to tailor the process to the nature of the work.
The Big Admin Gotcha: Workflow Schemes and Shared Impact
This is perhaps the most critical takeaway from this entire video: spaces don’t own workflows directly. Instead, they use workflow schemes, and those schemes can be shared across multiple spaces.
This means that if you edit a workflow scheme, your change might impact not just the space you’re looking at, but every other space that uses that same scheme. This is what’s sometimes referred to as the “blast radius” of a configuration change. The golden rule for any Jira admin is simple: always check where a scheme is used before editing it. Taking a moment to verify shared usage can save you from accidentally disrupting workflows across your entire organization.
What’s Coming in Part 4
In the next part of our Jira Admin Essentials series, we’ll cover the other half of space configuration, specifically fields, screens in more depth, and permissions. These are the settings that control what users see on their work items and what they’re allowed to do within a space. Stay tuned for Part 4, where we dive deeper into the configuration layers that shape the complete Jira admin experience.
