ExamFinch.com My Study

Study guide

5.2 Custom Field Types, Global vs. Project Contexts & Options

Practice this exam

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.2 Custom Field Types, Global vs. Project Contexts & Options

Key Takeaways Explain This Topic AI

Jira Cloud provides diverse built-in custom field types (Select lists, Text fields, Date/Time, User/Group pickers, Labels), each dictating data storage, indexing format, validation, and JQL query syntax.

System fields (Summary, Priority, Assignee) are hardcoded into the Jira engine, whereas locked custom fields (Story Points, Sprint, Epic Link / Parent) are provisioned by Jira Software and cannot be deleted or retyped.

Custom Field Contexts define the project and issue-type scope of a field, enabling administrators to reuse a single field across multiple departments with distinct option lists and default values.

Team-managed projects create project-scoped fields (up to 50 per project) that can't be shared with other projects; company-managed fields are global and scoped with contexts.

Disable select-list options instead of deleting them when retiring a choice: disabling blocks new selections but keeps historical values and JQL results intact.

Last updated: September 2026

Custom Field Types, Global vs. Project Contexts & Options

While Jira Cloud delivers dozens of core system fields to capture standard project metadata, enterprise business workflows inevitably require capturing organization-specific information. Custom fields allow Jira administrators to extend the native issue data model to capture cost centers, compliance ratings, client account identifiers, hardware serial numbers, and custom delivery milestones.

However, unmanaged custom field creation is one of the most common causes of administrative degradation in Jira Cloud. Creating separate, redundant fields for every team clutters JQL searches, degrades browser rendering performance, and fragments cross-organizational analytics. The ACP-120 exam heavily evaluates your ability to select appropriate field types, leverage Custom Field Contexts to reuse fields, and manage option lifecycles responsibly.

Custom Field Types: Built-in Capabilities and Selection Criteria

Jira Cloud provides a wide spectrum of built-in custom field types accessible via Cog (Settings) > Issues > Custom fields > Create custom field . Choosing the correct field type is a permanent structural decision: once a custom field is created, its underlying data type cannot be changed .

Field Type Category Specific Custom Field Type Typical Administrative Use Cases JQL Search Syntax & Behavior

Select Lists Select List (single choice) Fixed, mutually exclusive choices (e.g., Severity: Critical, Major, Minor) cf[10050] = "Critical" or Severity = "Critical"

Select List (multiple choices) Selecting multiple applicable tags from a controlled list Tags in ("Security", "Audit")

Select List (cascading) Two-level hierarchical dependent dropdowns (Parent -> Child) Department in cascadeOption("Finance", "Payroll")

Radio Buttons Mutually exclusive choices where all options must be visible at once "Approve Deployment" = "Yes"

Checkboxes Multiple selectable options where all choices are visible simultaneously "Compliance Checks" in ("GDPR", "HIPAA")

Text Fields Text field (single line) Short strings up to 255 characters (e.g., Purchase Order #, External ID) "PO Number" ~ "PO-998*" (text search matching)

Text field (multi-line) Long-form narratives; supports Wiki Style / ADF rich text rendering "Root Cause Analysis" ~ "buffer overflow"

Pickers User Picker (single user) Assigning secondary user roles (e.g., QA Lead, Product Approver) "Security Reviewer" = currentUser()

User Picker (multiple users) Assigning collaborative review panels or stakeholder distribution lists "Stakeholders" in (currentUser(), membersOf("finance-leads"))

Group Picker (single/multiple) Restricting or routing work to designated access groups "Approval Group" = "finance-directors"

Dates & Numbers Date Picker Specific calendar dates without timestamps (e.g., Target Release Date) "Target Date" <= endOfWeek()

Date Time Picker Exact chronological timestamps with time-of-day (e.g., Incident Outage Time) "Outage Started" >= "2026-09-01 08:00"

Number Field Real floating-point or integer values (e.g., Financial Cost, Story Points) "Cost Estimate" > 5000 (supports numerical comparison operators)

Labels Labels Free-form, user-generated tagging without administrative pre-configuration Labels in ("q3_focus", "tech_debt")

The Cascading Select List

The Cascading Select List is a specialized two-tier dropdown designed to model parent-child relationships without requiring external apps.

Tier 1 (Parent) : Selects the broad domain (e.g., Hardware , Software , Network ).

Tier 2 (Child) : Dynamically populates with options specific to that parent (e.g., selecting Hardware surfaces Laptop , Monitor , Docking Station ; selecting Network surfaces VPN , Firewall , Switch ).

JQL Syntax : Querying cascading fields requires the specialized cascadeOption() function: "Asset Category" in cascadeOption("Hardware", "Laptop") If only the parent is specified, it returns all issues under that parent regardless of child selection: "Asset Category" in cascadeOption("Hardware")

System Fields vs. Custom Fields vs. Locked Fields

Understanding field origin and administrative restrictions is vital for governance and exam success:

1. System Fields

Built directly into the core Jira Cloud relational schema ( Summary , Description , Issue Type , Status , Priority , Resolution , Assignee , Reporter , Created , Updated ).

Cannot be deleted, renamed globally, or removed from the database.

Can be hidden, set to mandatory, or have descriptions altered via Field Configurations .

Do not possess Custom Field IDs (they use standard property keys like summary , priority ).

2. Standard Custom Fields

Created by Jira Administrators to meet business requirements.

Receive an auto-incrementing numerical identifier (e.g., customfield_10042 ).

Can be edited, re-scoped via contexts, associated with screens, or deleted entirely.

3. Locked Custom Fields

System-generated custom fields installed automatically by Atlassian products or apps (e.g., Story Points , Sprint , Epic Link , Epic Name , Rank , Development ).

Display a distinctive Lock Icon in the Custom fields administration console.

Cannot be deleted or have their field type altered by administrators, as doing so would break Jira Software agile boards, release burndown charts, or developer tool integrations.

Administrators can configure their screens, field configurations, and in some cases, custom field contexts.

Custom Field Contexts: Architecture and Power

A Custom Field Context (historically called a Custom Field Configuration Scheme ) defines the operational scope and behavior of a custom field. When a custom field is initially created, Jira assigns it a single Global Context , meaning the field applies to all projects and all issue types across the entire site.

However, administrators can create multiple Project- and Issue-Type-Specific Contexts for the same custom field. +-------------------------------------------------------------------------+

  • | Custom Field: "Operating Environment" |
  • +-------------------------------------------------------------------------+
  • |
  • +---------------------------+---------------------------+
  • | |
  • v v
  • +---------------------------------+ +---------------------------------+
  • | Context A | | Context B |
  • | Projects: Mobile App, Web App | | Projects: Core Banking (FIN) |
  • | Issue Types: Bug, Defect | | Issue Types: Change Request |
  • | Options: | | Options: |
  • | - iOS Production | | - Tier 1 Mainframe Prod ||
  • | - Android Production | | - Disaster Recovery Vault |
  • | - Staging Sandbox | | - Regulatory Audit Mirror |
  • | Default: Staging Sandbox | | Default: Tier 1 Mainframe Prod |
  • +---------------------------------+ +---------------------------------+

What Can Be Customized per Context?

Within each context of a custom field, an administrator can independently configure:

Applicable Projects : Restrict the field to specific projects, or leave as global.

Applicable Issue Types : Restrict the field to specific issue types (e.g., only Bug ), or apply to all issue types.

Available Options : Present completely different option lists for select lists, checkboxes, and radio buttons.

Default Value : Establish a different default selection tailored to that specific project's workflow.

User / Group Filtering : For User Picker fields, filter selectable users by specific groups or project roles per context.

The Strategic Value of Contexts vs. Field Proliferation

Consider an enterprise where the Software Development team, IT Operations team, and Marketing team all need an "Approval Status" dropdown with different approval stages.

The Anti-Pattern (Field Proliferation) : Creating three separate fields: Dev Approval Status , IT Approval Status , and Marketing Approval Status .

Result : Users searching globally must write convoluted JQL: "Dev Approval Status" = Approved OR "IT Approval Status" = Approved OR "Marketing Approval Status" = Approved , and every new team adds another field to maintain.

The Best Practice (Contextual Reuse) : Creating a single custom field named Approval Status and configuring three separate project contexts.

Result : Each team sees only their relevant options. JQL reporting is unified: "Approval Status" = Approved , and there's one field to govern.

Important

A custom field can have multiple contexts, but a project and issue type combination can only match ONE context per custom field . You cannot map Project A to two different contexts for the exact same field; Jira will reject overlapping context definitions.

Managing Select List Options: Add, Edit, Reorder, and Disable

Managing the lifecycle of options within select lists requires strict adherence to administrative procedures to prevent data corruption:

Adding Options

New options can be added at any time within Custom fields > ... > Contexts and default value > Edit Options . New options appear immediately in the issue interface for matching projects.

Editing Options (Renaming)

Renaming an existing option (e.g., changing "In Review" to "Under Peer Review") updates the display label dynamically across all existing issues that currently hold that value, as issues store the underlying option ID. Historical JQL queries matching the old string must be updated to the new string.

Deleting vs. Disabling Options (Critical Exam Concept)

When an enterprise decides to retire a choice from a select list, administrators face a critical choice:

Action Impact on Existing Issues Impact on New / Edited Issues Impact on JQL Searches

Disable Option Zero impact . Existing issues retain the option value; historical audit trails remain 100% intact. The option is hidden from the dropdown ; users cannot select it on new issues or when editing. JQL searches querying the disabled option continue to return all historical issues accurately.

Delete Option Destructive . Existing issues lose that value, so historical categorization is gone. The option ceases to exist anywhere in the dropdown. JQL searches for the deleted option no longer find the old issues.

Tip

Always disable, never delete. On the ACP-120 exam, whenever a scenario describes retiring a select list option while preserving historical integrity and reporting consistency, the correct administrative action is to Disable the option .

Adding Fields to Team-Managed Projects

Blueprint 3.2 also asks how fields are added in team-managed projects, which work very differently.

Topic Company-Managed Team-Managed

Who creates fields Jira admin, in Settings > Issues (Work items) > Custom fields Project admin, in Project settings > Fields or while editing an issue type

Scope Global field, narrowed with contexts The field belongs to that one project

Reuse across projects Yes, through contexts No. Team-managed fields can't be shared with other projects, and team-managed projects can't use company-managed custom fields

Where it appears Screens and issue layout Dragged into an issue type's Description fields or Context fields , or below the Hide when empty line

Limit Site-wide governance Up to 50 custom fields per team-managed project

Inside one team-managed project, a field can be reused across issue types. Those issue types then share its name, description, and (for dropdowns and checkboxes) its options, although each issue type can have its own default value. Because two team-managed projects that each create "Campaign Type" end up with two unrelated fields, cross-project reporting is harder than in company-managed projects that share one field with contexts.