Jira Admin Guide: Fields, Screens & Permissions Explained

Jira Admin Guide: Fields, Screens & Permissions Explained

Learn how to configure Jira fields, screens, and permissions like a pro. Control access, reduce clutter, and keep your instance secure and scalable.

Table of Contents

In this final part of our Jira Admin Essentials series, we walk through how to configure fields, screens, and permissions in Jira so you can control what users see, what they can edit, and what actions they’re allowed to perform. By understanding these core building blocks, you’ll avoid common pitfalls like bloated field lists and inconsistent access control, keeping your Jira instance fast, clean, and secure.

This guide covers everything from creating custom fields and field configurations to setting up screens, permission schemes, space roles, issue security levels, and using the audit log to track admin changes.

Watch our full walkthrough in the video below:

Fields: The Data You Capture on Issues

Fields are the foundation of every Jira issue. They represent the data you capture each time a work item is created or updated. Jira comes with a set of standard fields out of the box, including Summary, Description, and Priority. These cover the basics for most workflows, but as your organization’s needs grow, you’ll likely want to extend them.

That’s where custom fields come in. As admins, you can create custom fields such as dropdowns (select lists), date pickers, user pickers, and status-like custom fields. In our video, Marvin demonstrates how to create a new field by navigating to the fields section under Jira work items, clicking “Create new field,” selecting the field type, giving it a name, and optionally adding a description so other users understand its purpose.

The Danger of Too Many Fields

One of the most important warnings we share in this video is about field sprawl. Creating too many fields is one of the fastest ways to make Jira slow and confusing for end users. Every custom field you add increases the complexity of your instance, impacts performance, and can clutter create and edit screens. The rule of thumb is simple: only create a field when you genuinely need and will use the data it captures. If you’re not actively reporting on or filtering by a field, reconsider whether it’s necessary.

Field Configurations: Rules for Your Fields

Once you have your fields in place, the next layer of control is field configurations. Field configurations determine the rules that govern each field’s behavior. Specifically, they control whether a field is required, hidden, or given a default value.

This is a powerful tool for simplifying the issue creation form. For example, you can hide rarely used fields so they don’t overwhelm users during issue creation, and you can mark only the essential fields as required. This strikes the right balance between capturing important data and keeping the user experience clean and efficient.

It’s important to understand the distinction here: field configurations define the rules about fields, while screens (covered next) define what users actually see. These are two separate but complementary layers of configuration.

Screens: What Users Actually See

Screens are one of the most impactful configuration elements in Jira. They control which fields appear on the Create, Edit, and View screens for issues. This means you have granular control over what information is presented to users at different stages of interacting with a work item.

In our demo, Marvin shows how screens are created per space and how you can tailor the user experience for different teams or workflows. The key distinction to remember is that field configurations control the rules (required, hidden, default), while screens control visibility. You might have a field that exists and is optional per the field configuration, but it won’t appear to users unless it’s added to the relevant screen.

By carefully managing your screens, you can ensure that users only see the fields that are relevant to their workflow, reducing confusion and improving data quality.

Permissions: The Security Side of Jira

Permission schemes represent the security backbone of your Jira instance. They define who can perform specific actions, including browsing spaces, creating work items, editing work items, transitioning work items through workflows, and administering spaces.

Permissions can be assigned through multiple mechanisms: groups, space (project) roles, or specific individual users. While assigning permissions to specific users might seem straightforward, it doesn’t scale well. This is where space roles become essential.

Space Roles and Scalable Permission Management

Space roles such as Administrator, Developer, and Viewer are assigned at the space (project) level and then referenced in permission schemes. This approach is what makes access control consistent and scalable across your entire Jira instance. Instead of managing permissions user by user, you assign users to roles within each space, and the permission scheme handles the rest.

In our demo, Marvin navigates to the space settings to show how space roles are configured and how they connect back to the permission scheme. This architecture means that when you need to change who can do what, you update the role assignment rather than rewriting permission rules, saving significant administrative effort.

Issue Security: Restricting Visibility for Sensitive Work

Sometimes you need to go beyond standard permissions and restrict who can see specific issues within a space. This is where issue security levels come in. Issue security allows you to limit visibility of sensitive work items to only certain users, groups, or roles, even within a space where others normally have browse access.

Issue security is configured through an Issue Security Scheme, which you associate with a specific space. As Marvin points out in the video, this feature may not be enabled by default. You’ll need to navigate to the space settings, go to the work item security section, and either select an existing scheme or create a new one. This is a critical step for teams handling confidential or sensitive information within shared Jira spaces.

The Audit Log: Tracking Admin Changes

One feature that’s often overlooked but incredibly valuable is the audit log. The audit log tracks all admin changes in your Jira instance, recording who changed what and when. This is essential for both troubleshooting and governance.

In our video, Marvin navigates to the Jira admin system settings under troubleshooting to show the support audit log. There you can see entries such as when a custom field was created and by which account. If something breaks or an unexpected change appears in your instance, the audit log is your first stop for investigation. Make it a habit to check this log regularly, especially after configuration changes.

Putting It All Together: Your Next Step Exercise

Now that you understand the layers of Jira configuration, from fields and field configurations to screens, permissions, and security, it’s time to apply this knowledge. Our recommended next step exercise is straightforward and high value:

  • Open one real space in your Jira instance
  • Identify the Issue Type Scheme assigned to it
  • Identify the Workflow Scheme in use
  • Identify the Permission Scheme applied

Reviewing these three schemes for a single space will teach you an enormous amount about how your Jira instance is wired. You’ll see how issue types, workflows, and permissions interconnect, giving you a practical understanding that goes far beyond theory. Combined with the knowledge from the earlier parts of this series, covering space admin basics, work item types, and workflows, you now have a complete roadmap for managing Jira as an admin with confidence.

Subscribe to our newsletter:

Related articles: