Study guide
5.4 Screens, Screen Schemes & Issue Type Screen Schemes
Atlassian Certified Professional - Jira Administration for Cloud ACP-120
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Exam Overview, Blueprint & Jira Cloud Fundamentals
1.1 ACP-120 Exam Structure, Blueprint & Testing Strategy 1.2 Jira Cloud Architecture, Products & Admin Hierarchy
2 Chapter 2: Organizations, Managed Accounts & Global Access
2.1 Atlassian Organizations, Domain Verification & Managed Accounts 2.2 Atlassian Guard, SAML SSO, SCIM & Authentication Policies 2.3 Site Access, Product Access Tiers & Global Permissions 2.4 User Directory Architecture: Groups vs. Project Roles
3 Chapter 3: Project Permissions & Issue-Level Security Schemes
3.1 Permission Scheme Mechanics & Critical Project Permissions 3.2 Permission Troubleshooting, Additive Permissions & Permission Helper 3.3 Issue Security Schemes, Security Levels & Access Containment
4 Chapter 4: Project Configuration, Types, Versions & Boards
4.1 Company-Managed vs. Team-Managed Project Architecture 4.2 Project Templates, Project Keys & Project Categories 4.3 Project Components, Component Leads & Default Assignees 4.4 Versions, Fix Versions, Release Lifecycles & Project Archiving 4.5 Scrum and Kanban Board Configuration, Board Filters & Columns
5 Chapter 5: Issue Types, Custom Fields, Screens & Schemes
5.1 Standard vs. Sub-task Issue Types & Issue Type Schemes 5.2 Custom Field Types, Global vs. Project Contexts & Options 5.3 Field Configurations, Renderers, Hiding & Required Fields 5.4 Screens, Screen Schemes & Issue Type Screen Schemes
6 Chapter 6: Workflows — Company-Managed and Team-Managed
6.1 Statuses, Status Categories, Direct & All-to-One Global Transitions 6.2 Transition Rules: Conditions vs. Validators 6.3 Post Functions, Execution Order & Resolution Management 6.4 Workflow Schemes, Editing Active Workflows & Status Migration 6.5 Team-Managed Workflows, Statuses & Workflow Rules
7 Chapter 7: Jira Cloud Automation
7.1 Automation Engine, Rule Architecture & Event Triggers 7.2 Automation Conditions, Smart Values & String/Date Expressions 7.3 Branch Rules, Related Issues, Sub-tasks & Parent Epics 7.4 Rule Scopes, Automation Usage, Audit Logs & Error Handling
8 Chapter 8: Notifications, Events, Personal Settings & Mail Handlers
8.1 Jira Events, System Events & Notification Schemes 8.2 Notification Recipients, Custom User Fields & Deduplication 8.3 Team-Managed Notifications, Personal Settings & Troubleshooting Missing Email 8.4 Mail Handlers: Creating Issues and Comments from Email
9 Chapter 9: JQL, Filters, Dashboards & Bulk Operations
9.1 JQL Fundamentals, Clauses, Operators & History (WAS / CHANGED) 9.2 Advanced JQL Functions & Dynamic Date Searches 9.3 Filter Permissions, Shared Filters & Filter Subscriptions 9.4 Dashboard Layouts, the Default Dashboard, Sharing & Essential Gadgets 9.5 Bulk Operations: Edit, Move, Transition, Delete & Watch
10 Chapter 10: System Administration
10.1 Global UI Features: User Defaults, Look and Feel, Announcement Banner & Default Dashboard 10.2 Statuses, Resolutions, Priorities & Sub-tasks: Global Configuration 10.3 Global Settings: Time Tracking, Issue Linking, Attachments & Application Links 10.4 System Backup, Restore & Data Import
5.4 Screens, Screen Schemes & Issue Type Screen Schemes
Key Takeaways Explain This Topic AI
Jira Cloud screen architecture operates on a strict 3-tier mapping model: Screen -> Screen Scheme -> Issue Type Screen Scheme -> Project.
Individual Screens define the visual arrangement of fields, allowing administrators to group related fields into logical Screen Tabs to prevent user cognitive overload.
Screen Schemes map specific issue operations (Create Issue, Edit Issue, View Issue) to distinct screens; any unmapped operation automatically inherits the screen mapped to Default.
Issue Type Screen Schemes map different issue types within a project to specific Screen Schemes, enabling tailored screen layouts (e.g., diagnostic fields on Bugs vs. minimal fields on Tasks).
Company-managed issue layouts arrange the fields from each issue type's View screen into description, context, and hide-when-empty areas; team-managed issue types use one drag-and-drop layout with no screens.
Last updated: September 2026
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
Where tabs appear : In the current issue view, the tabs of the issue type's screen appear in the description area of the issue.
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.
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:
Issue Operation When It Triggers Recommended Design Strategy
Create Issue When a user clicks the global Create button or clones an issue Keep minimal . Include only mandatory and essential classification fields to encourage adoption and reduce reporting friction.
Edit Issue When a user opens the full Edit modal dialog Comprehensive . Expose operational, estimation, and secondary fields that become relevant during active execution.
View Issue When a user opens the issue details page or backlog detail panel Comprehensive . Display all informative fields, timestamps, and contextual metadata.
Default Fallback for any unmapped operation Acts as the universal fallback screen.
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:
Default Screen Scheme : The fallback screen scheme applied to any issue type not explicitly mapped. Every ITSS must have a Default mapping.
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 :
Go to Settings > Issues (Work items) > Workflows and edit the target workflow.
Select the transition (for example, Resolve Issue ).
In the transition's Rules , add the Show a screen rule (the "Request input" rule group, which replaces the old transition Screen field).
Choose the screen (for example, Jira's built-in Resolve issue screen or your own).
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:
Layout Area Where It Shows Typical Fields
Description fields The main (left) area of the issue Description, Environment, other multi-line text fields; the screen's extra tabs also appear here
Context fields The right-hand Details panel Assignee, Reporter, Priority, Labels, Components, Fix versions
Hide when empty (below the divider in context fields) Collapsed under More fields until the field has a value Rarely used fields
Hidden fields Not shown at all Fields you want off this issue type's view
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) :
Select the issue type.
Drag fields from the field panel into Description fields or Context fields .
Drag rarely used fields below the Hide when empty line.
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.