5.4 Screens, Screen Schemes & Issue Type Screen Schemes

Screens, Screen Schemes & Issue Type Screen Schemes

Screens represent the user interface layer of Jira Cloud. Whenever an end user creates an issue, reviews issue details, edits field values, or transitions a workflow status, they interact directly with a Screen. However, screens do not exist in isolation; they are governed by a sophisticated 3-tier architectural framework that enables enterprise administrators to reuse screen layouts, vary screens by issue operation, and tailor field visibility across diverse issue types.

Mastering this 3-tier hierarchy—and understanding how workflow Transition Screens intersect with it—is essential for passing the ACP-120 exam and designing maintainable enterprise configurations.

---

The 3-Tier Screen Architecture

To manage screens at scale, Jira decouples individual screen design from project assignments through three hierarchical tiers:

+-------------------------------------------------------------------------+
|                        The 3-Tier Screen Framework                      |
+-------------------------------------------------------------------------+

   Tier 1: SCREENS (Cog > Issues > Screens)
   - Individual canvases containing an ordered list of fields and tabs
   - Example: "Defect Create Screen", "Standard View Screen", "Resolve Screen"
                                     |
                                     v
   Tier 2: SCREEN SCHEMES (Cog > Issues > Screen schemes)
   - Maps Issue Operations (Create, Edit, View) to individual Screens
   - Example: "Bug Screen Scheme" (Create -> Defect Create Screen; Default -> Standard View Screen)
                                     |
                                     v
   Tier 3: ISSUE TYPE SCREEN SCHEMES (Cog > Issues > Issue type screen schemes)
   - Maps Issue Types (Bug, Story, Task) to Screen Schemes
   - Example: "Enterprise Software ITSS" (Bug -> Bug Screen Scheme; Default -> Standard Screen Scheme)
                                     |
                                     v
   PROJECT ASSOCIATION (Project settings > Screens)
   - Exactly ONE Issue Type Screen Scheme is applied to a company-managed project

Why This Hierarchy Exists

Consider an organization with 50 development projects. If an administrator needed to add a new "Compliance Check" field to all Bug creation screens, direct project-to-screen binding would require editing 50 separate configurations. Under the 3-tier model, the administrator updates a single shared Screen, and the change instantly propagates across all 50 projects.

---

Tier 1: Screens and Screen Tabs

A Screen is a container that organizes fields vertically for user interaction (Cog (Settings) > Issues > Screens).

Screen Tabs

When an issue requires dozens of fields (common in IT Service Management, HR onboarding, or regulated medical software), placing all fields on a single scrolling page creates severe cognitive fatigue. Administrators use Screen Tabs to organize fields logically:

• Tab 1: General Information (Summary, Description, Priority, Component)
• Tab 2: Technical Environment (Operating System, Database Version, Build Number)
• Tab 3: Customer / Billing (Account ID, Service Tier, Billing Code)

Screen Tab Behavior Rules

1. Where tabs appear: In the current issue view, the tabs of the issue type's screen appear in the description area of the issue.
2. Who configures tabs: Only Jira admins can create, rename, reorder, or delete tabs and change the fields on them. Project admins can't change tab contents.
3. Tab Deletion: Deleting a tab from a screen does not delete the fields from Jira; it merely removes those fields from that screen.

---

Tier 2: Screen Schemes and Operation Mapping

A Screen Scheme (Cog > Issues > Screen schemes) controls which Screen appears during each of the three primary issue operations:

The Fallback Mechanism

Every Screen Scheme requires an entry mapped to the Default operation. If an administrator creates a Screen Scheme and only maps the Create Issue operation to a specialized "Lightweight Create Screen", leaving Edit and View unmapped, Jira automatically routes both the Edit Issue and View Issue operations to the screen mapped to Default.

Example Configuration: "Development Screen Scheme"
- Create Issue  ------> "Quick Create Screen" (Summary, Description, Priority, Component)
- Default       ------> "Comprehensive Screen" (Includes all above + Story Points, Fix Version, Assignee)

Result:
- Creating an issue uses "Quick Create Screen"
- Editing an issue uses "Comprehensive Screen" (inherited from Default)
- Viewing an issue uses "Comprehensive Screen" (inherited from Default)

---

Tier 3: Issue Type Screen Schemes (ITSS)

An Issue Type Screen Scheme (Cog > Issues > Issue type screen schemes) sits at the top of the screen hierarchy, linking issue types to specific Screen Schemes.

Configuration Mechanics

Within an Issue Type Screen Scheme, the administrator defines:

1. Default Screen Scheme: The fallback screen scheme applied to any issue type not explicitly mapped. Every ITSS must have a Default mapping.
2. Issue Type Mappings: Specific associations that override the default (e.g., mapping Bug to the Bug Screen Scheme, and Epic to the Epic Screen Scheme).

Project Association

A company-managed project is associated with exactly one Issue Type Screen Scheme via Project settings > Screens. To switch schemes, an administrator clicks Actions > Use a different scheme.

---

Transition Screens: Workflow Screen Binding

One of the most vital architectural boundaries in Jira is the distinction between Screen Schemes and Transition Screens.

Screen Schemes govern standard CRUD operations (Create, Edit, View). However, when an issue moves through a workflow lifecycle, specific transitions require capturing data at the exact moment of state change. These are handled via Transition Screens.

+-------------------------------------------------------------------------+
|               Screen Scheme vs. Transition Screen Scope                 |
+-------------------------------------------------------------------------+

    STANDARD CRUD OPERATIONS                   WORKFLOW TRANSITION
    
    +-------------------------+            +-------------------------+
    |      Create Screen      |            |    "In Progress" Status | 
    +-------------------------+            +-------------------------+
                 |                                      |
                 v                                      v  [Transition: Resolve]
    +-------------------------+            +-------------------------+
    |    Edit / View Screen   |            |    TRANSITION SCREEN    |
    |  (Governed by ITSS &    |            |  - Prompt for Resolution|
    |      Screen Schemes)    |            |  - Prompt for Fix Ver   |
    +-------------------------+            +-------------------------+
                                                        |
                                                        v
                                           +-------------------------+
                                           |     "Done" Status       |
                                           +-------------------------+

Binding a Transition Screen

Transition screens are not configured inside Screen Schemes. They are attached to a transition in the workflow editor:

1. Go to Settings > Issues (Work items) > Workflows and edit the target workflow.
2. Select the transition (for example, Resolve Issue).
3. In the transition's Rules, add the Show a screen rule (the "Request input" rule group, which replaces the old transition Screen field).
4. Choose the screen (for example, Jira's built-in Resolve issue screen or your own).
5. Select Update workflow to publish the change.

The Resolution Field Best Practice

The Resolution field marks an issue as formally complete in Jira Cloud. Its presence or absence determines whether an issue is considered open or closed across JQL filters (resolution is EMPTY), board strikethroughs, and version release reports.

[!CAUTION] Never put the Resolution field on a Create Screen or Edit Screen. If placed on standard screens, users can set a resolution while the issue is still active, or clear it inadvertently. The Resolution field should ONLY appear on Transition Screens leading to terminal status categories ("Done"), or be set automatically via the Update Issue Field workflow post-function.

---

Issue Layout in Company-Managed Projects (Blueprint 3.3)

Screens decide which fields exist for each operation. The issue layout decides where those fields appear when someone opens the issue. Project admins configure it from an issue (Configure > Work item view) or from project settings, and it has three areas:

Rules the exam likes to test:

• The available fields come from the View screen. If a field isn't on the screen used for viewing that issue type, it can't be placed in the layout. Adding a field to that screen is a Jira admin task.
• Issue types that share a View screen share a layout. By default, tasks and sub-tasks often use the same View screen, so you configure their layout together.
• Layouts are per project. Changing one project's layout doesn't change another's. You can copy a layout to other projects that use the same screen.
• Delegation: a non-admin with the Manage work item layouts permission can change the layout only if its screens aren't shared with other projects.
• Personal pinning: each user can pin their favorite context fields to the top of the Details panel. That's a personal preference, not an admin setting.

---

Screens for Issue Types in Team-Managed Projects

Team-managed projects have no screens, screen schemes, or issue type screen schemes. The project admin configures each issue type directly in Project settings > Issue types (Work types):

1. Select the issue type.
2. Drag fields from the field panel into Description fields or Context fields.
3. Drag rarely used fields below the Hide when empty line.
4. Save. The same layout is used when creating, viewing, and editing that issue type.

Because each team-managed issue type has one layout, you can't show a different set of fields on create than on view, as you can with company-managed screen schemes.