ExamFinch.com My Study

Study guide

5.3 Field Configurations, Renderers, Hiding & Required Fields

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.3 Field Configurations, Renderers, Hiding & Required Fields

Key Takeaways Explain This Topic AI

Field Configurations govern four essential issue field behaviors: Required vs. Optional, Hidden vs. Visible, Field Description (contextual help text), and Renderer Type (for rich-text fields).

Field Configuration Schemes bind specific issue types within a project to distinct Field Configurations, allowing different field rules (e.g., requiring Steps to Reproduce only on Bugs).

Setting a field to Required in a Field Configuration enforces validation everywhere the issue type is processed; if omitted from a Create Screen, issue creation via UI, REST API, or mail handlers fails.

Hiding a field in a field configuration removes it everywhere for those issue types; leaving it off a screen only removes it from that form, and automation rules can still update it.

Renderers dictate how text fields are formatted, providing a choice between the Default Text Renderer (unformatted plain text) and the Wiki Style Renderer (rich text with markdown, tables, and macro formatting).

Last updated: September 2026

Field Configurations, Renderers, Hiding & Required Fields

While Custom Fields define what data can be captured and Screens define where fields are visually arranged, Field Configurations define how fields behave. A Field Configuration acts as the behavioral engine for every field in Jira—whether system or custom—dictating whether a field is mandatory, whether it is visible, what help instructions are displayed beneath it, and which rendering engine processes its text.

On the ACP-120 exam, Field Configurations represent one of the most critical testing areas. Many complex troubleshooting scenarios hinge on understanding why an integration broke, why a user cannot submit an issue, or how hiding a field in a Field Configuration fundamentally differs from leaving it off a screen.

The Anatomy of a Field Configuration

Field Configurations are managed globally at Cog (Settings) > Issues > Field configurations . Every Jira Cloud instance includes a system-default configuration named Default Field Configuration .

Inside any Field Configuration, every system and custom field in the instance is listed alphabetically, exposing four administrative levers: +-----------------------------------------------------------------------------------------+

  • | Field Configuration Levers |
  • +-----------------------------------------------------------------------------------------+
  • | 1. Required / Optional | Enforces whether the field must contain a value (Red asterisk) |
  • | 2. Hide / Show | Toggles global visibility on/off for this configuration |
  • | 3. Edit (Description) | Sets contextual help text displayed immediately below field |
  • | 4. Renderers | Selects rendering engine for text fields (Default vs. Wiki) |
  • +-----------------------------------------------------------------------------------------+
  • 1. Required vs. Optional

Required : The field cannot be empty. If a user attempts to create or transition an issue without supplying a value, Jira halts the operation and renders an error banner.

Optional : The field may remain null/empty.

2. Hide vs. Show

Hide : The field is completely suppressed from view across the entire project for issue types using this configuration.

Show : The field is active and eligible to be displayed on screens.

3. Edit (Field Description / Help Text)

Allows customizing the descriptive text that appears beneath the field input box. This is an enterprise best practice for guiding users on format requirements (e.g., "Enter the 8-digit SAP vendor ID starting with V-" ).

Field descriptions configured in a Field Configuration override any global description set on the custom field itself.

4. Renderers

Applicable to multi-line text (paragraph) and certain system fields (like Environment and Description ).

Toggles between the Default Text Renderer (plain, unformatted monospace or sans-serif text) and the Wiki Style Renderer (rich text rendering supporting bulleted lists, numbered lists, tables, colored text, hyperlinks, inline images, and user @mentions ).

Field Configuration Schemes: Mapping to Issue Types

A single project often tracks diverse issue types with radically different data requirements. For example, a software project needs Steps to Reproduce to be mandatory on Bug issues, but Steps to Reproduce should not even appear on Story or Task issues.

A Field Configuration Scheme ( Cog > Issues > Field configuration schemes ) bridges this requirement by mapping specific issue types to distinct Field Configurations within a project. +-------------------------------------------------------------------------+

  • | Software Field Configuration Scheme |
  • +-------------------------------------------------------------------------+
  • |
  • +---------------------------+---------------------------+
  • | |
  • v v
  • +---------------------------------+ +---------------------------------+
  • | Bug Issue Type | | Default (All other types) |
  • | | | | | |
  • | v | | v |
  • | "Bug Field Configuration" | | "Standard Field Configuration" |
  • | - Steps to Reproduce: REQUIRED | | - Steps to Reproduce: HIDDEN |
  • | - Environment: WIKI RENDERER | | - Story Points: OPTIONAL |
  • | - Fix Version/s: OPTIONAL | | - Due Date: OPTIONAL |
  • +---------------------------------+ +---------------------------------+
  • Unmapped Issue Types and the Default Entry

Every Field Configuration Scheme contains a mandatory entry labeled Default . Any issue type in the project that is not explicitly mapped to a specialized configuration automatically inherits the rules defined in the Default configuration. This ensures that even if a new issue type is later added to the project's Issue Type Scheme, it will always have a valid field configuration.

The Cardinal Rule of Required Fields and Creation Failures

One of the most frequent real-world disasters—and classic ACP-120 exam questions—involves breaking issue creation mechanisms by improperly configuring Required fields.

The Golden Rule

Caution

If a field is configured as Required in a Field Configuration, put it on the Create screen for that issue type (or give it a default value in its context). Automation rules run only after an issue exists, so they can't satisfy a field that's required at creation.

What Happens When This Rule Is Broken?

User Web Interface : A user clicks Create , selects the project and issue type, fills out all displayed fields, and clicks Create . Jira attempts to validate the issue against the Field Configuration. Because the required field is empty, validation fails. But because the field was omitted from the Create Screen, the user cannot see the field or enter a value . The UI displays an error: "Field '[Field Name]' is required and cannot be empty." The user is completely blocked from creating work.

REST API Integrations : Scripts or CI/CD pipelines calling POST /rest/api/3/issue fail with HTTP 400 Bad Request if they omit the required field. If they try to send it and the field isn't on the Create screen, Jira rejects that too: "Field '…' cannot be set. It is not on the appropriate screen, or unknown." The fix is to put the required field on the Create screen (or supply a default value).

Email-to-Issue Handlers : Incoming mail handlers can't ask senders for custom field values. If the project's field configuration makes a field required that the handler can't fill, issue creation from email fails. The handler's Forward Email option sends a status message to an address you choose, which is how admins spot these failures.

CSV & External Data Imports : Bulk imports fail on record validation unless the required field is mapped in the CSV import wizard.

Hiding via Field Configuration vs. Omitting from a Screen

Understanding the distinction between hiding a field in a Field Configuration versus leaving it off a Screen is a foundational competency tested extensively on the exam.

Evaluation Dimension Hidden via Field Configuration Left Off a Screen

Scope Everywhere for the issue types that use that field configuration Only the operation that uses that screen (for example, missing from Create but present on View)

Issue view Never shown, even if the issue already holds a value Shown if the field is on the View screen and the issue layout

Bulk edit Not offered. Bulk edit requires that the field isn't hidden in any field configuration the selected issues use Offered if the user has the needed permissions

Standard REST API create/edit Can't be set Can't be set through that screen. Jira returns "Field '…' cannot be set. It is not on the appropriate screen, or unknown."

Jira automation rules Treat as unavailable for that issue type Can still update it. Atlassian notes that automation rules bypass the screen scheme and can edit fields that aren't on the Edit screen

Best use The field genuinely doesn't apply to those issue types Keep the field out of a particular form without removing it from the issue type Scenario: "A 'Risk Score' field must be set only by our vulnerability scanner.

People must never type into it, but analysts must search and report on it."

WRONG: Hide the field in the field configuration.

- Result: The field disappears for those issue types, can't be bulk-edited,

and can't be set by the scanner.

WRONG: Leave it off every screen and have the scanner call the REST API

with a normal API token.

- Result: The API rejects the update: the field isn't on the appropriate screen.

  • CORRECT: Keep the field visible (not hidden) in the field configuration, keep it
  • off the Create and Edit screens, and have the scanner call an automation rule

(for example, an incoming webhook trigger) whose Edit issue action sets it.

- Result: People can't edit it, automation updates it, and it stays searchable.

Text Renderers: Default Text vs. Wiki Style Renderer

When a multi-line text field is created, Jira Cloud assigns it the Default Text Renderer . In this mode, text is stored and rendered as raw, plain ASCII/Unicode text.

The Wiki Style Renderer

Switching a field to the Wiki Style Renderer (configured via Field configurations > [Configuration] > [Field] > Renderers ) enables rich formatting powered by the Atlassian Document Format (ADF):

Headings ( h1. , h2. ), bold ( *bold* ), italics ( _italics_ ), and strikethrough.

Bulleted lists ( * ), numbered lists ( # ), and task checkboxes.

Data tables with column headers and cell formatting.

Code blocks with syntax highlighting ( {code:java}...{code} ).

Inline macro support and media attachments.

User mentions ( @username ) that trigger native Jira notification events.

Administrative Cautions When Changing Renderers

When an administrator switches a field's renderer from Default Text to Wiki Style (or vice versa) on an active instance, Jira displays a warning modal. Changing the renderer affects all existing issues using that Field Configuration. If users previously typed characters like brackets [ ] , asterisks * , or braces { } expecting them to display literally, the Wiki Style Renderer may attempt to parse them as markup macros, altering the visual appearance of historical records.