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

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.

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:

1. Applicable Projects: Restrict the field to specific projects, or leave as global.
2. Applicable Issue Types: Restrict the field to specific issue types (e.g., only Bug), or apply to all issue types.
3. Available Options: Present completely different option lists for select lists, checkboxes, and radio buttons.
4. Default Value: Establish a different default selection tailored to that specific project's workflow.
5. 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:

[!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.

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.