- Domain 5 Overview: What's Actually Tested
- Issue Types: Schemes, Hierarchies, and Sub-Tasks
- Custom Fields: Configuration, Context, and Scope
- Screens and Screen Schemes: Connecting Fields to Workflows
- Field Configuration and Field Configuration Schemes
- How Domain 5 Questions Are Framed on the Exam
- Understanding the Full Scheme Stack
- A Focused Preparation Plan for Domain 5
- Frequently Asked Questions
- Domain 5 covers 15-20% of the ACP-120 exam, making it one of the highest-weighted individual content areas you'll face.
- The exam tests issue type schemes, custom field contexts, screen schemes, and field configuration schemes - often in multi-step scenario questions.
- ACP-120 is administered through Atlassian University via Certiverse, costs approximately $249-$250 USD, and has a 63% passing threshold across up to 75...
- Custom field context scope - global vs. project-specific vs. issue-type-specific - is a consistently high-value topic for scenario-based items.
Domain 5 Overview: What's Actually Tested
Domain 5 - Issue Types, Fields and Screens - carries a 15-20% weight on the ACP-120 exam. That range places it firmly among the most important domains on the test. Only Domain 3: Product and Project Access and Permissions (30-35%) carries more weight. Every other domain sits at 5-15%, so the time you invest in Domain 5 delivers a meaningful return on your score.
What makes this domain challenging is not that any single concept is particularly obscure - it's that Jira Cloud uses a layered scheme architecture. Issue types connect to projects through issue type schemes. Fields connect to issue types through field configurations and field configuration schemes. Screens connect to workflows through screen schemes and issue type screen schemes. Understanding each layer independently is necessary but not sufficient; the exam tests whether you can reason through the interactions between layers, especially when a change in one scheme has downstream effects on project behavior.
If you haven't already mapped out how all eight domains fit together, the ACP-120 Exam Domains 2026: Complete Guide to All 8 Content Areas is a useful reference before diving deep into any single domain.
Issue Types: Schemes, Hierarchies, and Sub-Tasks
Issue Type Schemes
An issue type scheme defines which issue types are available in a project and in what order they appear to users. In Jira Cloud, every project is associated with exactly one issue type scheme. When you create a new company-managed project, Jira either assigns the default issue type scheme or creates a project-specific scheme depending on how the project was configured.
The exam tests practical administrative scenarios here - for example: a business team wants to add a new issue type called "Approval" to three specific projects without making it available globally. The correct path is to either modify a shared scheme (understanding the ripple effect on all associated projects) or create a project-specific scheme. Candidates who don't understand scheme sharing will consistently pick wrong answers on these items.
Issue Type Scheme - Key Administrative Facts
Understand these before sitting the exam:
- Jira Cloud ships with a Default Issue Type Scheme that all new projects inherit unless you specify otherwise.
- You can create custom issue type schemes and assign them to multiple projects simultaneously.
- Removing an issue type from a scheme does not delete existing issues of that type - it only prevents new ones from being created.
- Sub-task issue types are managed separately and cannot be used as standard issue types on the same project without reconfiguration.
- Team-managed (next-gen) projects do not use traditional issue type schemes in the same way as company-managed projects.
Sub-Tasks and Epic Hierarchies
Sub-task issue types have special behavior in Jira Cloud. They exist in a parallel list to standard issue types and can only be created as children of parent issues. The ACP-120 expects you to know when enabling sub-tasks is appropriate, how sub-task issue types are added and managed, and the administrative difference between sub-tasks in company-managed and team-managed projects.
Epic handling is also fair game. In Jira Software Cloud, Epics sit above Stories in the hierarchy, and Jira's roadmap features depend on this relationship. Exam questions may ask you to configure issue hierarchy or explain why a certain issue type cannot be linked in a particular way based on project type.
Custom Fields: Configuration, Context, and Scope
Field Types Available in Jira Cloud
Jira Cloud offers a wide range of custom field types - text fields, date fields, number fields, select lists (single and multi-value), cascading selects, user pickers, labels, URLs, checkboxes, and radio buttons, among others. The ACP-120 does not require you to memorize every field type, but it does expect you to know the behavioral differences between types that affect data entry and reporting. For example, a cascading select field requires a parent-child option structure and cannot be used the same way as a flat single-select list in filters and reports.
Custom Field Contexts - The Highest-Priority Subtopic
Field context is where most candidates lose marks in Domain 5. A custom field's context determines two things: which projects the field appears in, and which issue types within those projects display the field. A field can have multiple contexts, each with different default values and option lists. This is enormously powerful but also a common source of misconfiguration.
Common exam scenario: A finance team needs a custom "Cost Center" select field to appear only on Bug and Task issues within two specific projects, with a different option list than the one used by the engineering department's version of the same field. The correct answer involves creating separate contexts for each set of projects rather than using a single global context with one option list.
Field Options and Default Values
Within a field context, you can configure the options available in a select-type field and set a default value. Defaults are particularly important because they affect what value is pre-populated when a user creates a new issue. The exam may ask when setting a default value is appropriate and how defaults interact with required field configuration (covered under field configuration schemes, below).
| Custom Field Concept | What the ACP-120 Tests | Common Mistake |
|---|---|---|
| Global context | When it's appropriate vs. over-broad | Applying global context when only 2 projects need the field |
| Project-specific context | How to restrict field visibility to named projects | Forgetting that a field can have multiple contexts simultaneously |
| Issue-type-specific context | Scoping a field to certain issue types within a project | Assuming issue type restriction is set at the screen level instead |
| Option lists per context | How different teams can see different options for the same field | Creating duplicate fields instead of multiple contexts |
| Default values | How defaults interact with required field settings | Confusing field defaults with workflow property defaults |
Screens and Screen Schemes: Connecting Fields to Workflows
What a Screen Does
A screen in Jira controls which fields are visible to users during specific operations - issue creation, issue editing, and issue transition (during a workflow step). Adding a custom field to a context makes it available in Jira, but unless the field also appears on the relevant screen, users will never see it during data entry. This two-layer requirement (context + screen) is a fundamental concept that the exam tests repeatedly.
Screen Schemes and Issue Type Screen Schemes
A screen scheme maps the three operations (Create, Edit, View/Transition) to specific screens. An issue type screen scheme then maps different screen schemes to different issue types within a project. The full chain looks like this:
- Project → Issue Type Screen Scheme
- Issue Type Screen Scheme → Screen Scheme (per issue type)
- Screen Scheme → Screens (per operation: Create, Edit, Transition)
- Screen → Fields (specific fields visible during that operation)
Exam questions often present a scenario where a Jira admin needs a field to appear only during issue creation for Bug issue types, but not during editing. The correct answer requires understanding that you need a separate screen for the Create operation and that the screen scheme for the Bug issue type should use that dedicated screen for Create while using a different screen for Edit.
Key Takeaway
The most common Domain 5 scenario question pattern: a field appears on a context but users can't see it. Nine times out of ten, the field has not been added to the correct screen for the relevant operation. Check the screen before concluding there's a context or permission issue.
Field Configuration and Field Configuration Schemes
Field Behavior Settings
Field configuration is separate from both custom field contexts and screens. A field configuration controls three behavioral properties for each field within its scope: whether the field is required (users must enter a value), hidden (the field is suppressed entirely regardless of screen), or uses a specific renderer (e.g., wiki markup vs. text renderer for text fields).
Each field configuration is then applied to projects through a field configuration scheme, which maps specific field configurations to specific issue types. This allows you to make a field required for Bug issues but optional for Task issues within the same project.
Field Configuration Scheme - Exam-Critical Points
These details appear in scenario questions more often than candidates expect:
- A field configuration scheme maps issue types to field configurations; unassigned issue types use the Default field configuration.
- Hiding a field in a field configuration overrides screen placement - a hidden field will not appear even if it's on the screen.
- Making a field required in a field configuration means the workflow cannot transition past creation or transition screens without a value - this affects automation and bulk operations.
- Changing a renderer affects how existing field data is displayed retroactively, which can cause formatting issues in older issues.
How Domain 5 Questions Are Framed on the Exam
The ACP-120 uses up to 75 questions across 180 minutes, with multiple-choice, multiple-response, and scenario/configuration-reasoning items. Domain 5 questions almost exclusively fall into the scenario and configuration-reasoning category. You will rarely see a question that simply asks "what is a field configuration scheme?" - instead, you'll be presented with a situation like:
"A Jira admin adds a custom Date field to a project-specific context scoped to the 'Bug' issue type. Users report they cannot see the field when creating Bugs. The field is not hidden in the field configuration. What is the most likely cause?"
This type of question requires you to work through the scheme stack systematically. In this example, the field is in the right context and not hidden, so the problem must be that it hasn't been added to the Create screen used by the Bug issue type screen scheme. That's a three-layer reasoning chain - context → field configuration → screen - and getting it right requires genuine hands-on familiarity with Jira Cloud administration.
Understanding this question style is valuable across all domains. The Best ACP-120 Practice Questions 2026: What to Expect on the Exam covers how to approach these scenario items systematically, and the How Hard Is the ACP-120 Exam? Complete Difficulty Guide 2026 explains why configuration-reasoning questions catch even experienced admins off guard.
Understanding the Full Scheme Stack
One of the best investments you can make for Domain 5 is mapping out the complete scheme hierarchy on paper or in a diagram before exam day. The relationships are:
| Scheme Type | Controls | Assigned To |
|---|---|---|
| Issue Type Scheme | Which issue types exist in a project | Project |
| Field Configuration Scheme | Required/hidden/renderer per issue type | Project |
| Issue Type Screen Scheme | Which screen scheme applies per issue type | Project |
| Screen Scheme | Which screen appears for Create/Edit/Transition | Issue Type Screen Scheme |
| Screen | Which fields appear during an operation | Screen Scheme |
| Custom Field Context | Where a field is available and what options it has | Field (global or project-scoped) |
When a scheme is shared across multiple projects, changes to that scheme affect all associated projects simultaneously. This is a common exam trap: a question asks what happens when you modify a shared issue type scheme, and the correct answer accounts for the effect on all projects using that scheme, not just the one mentioned in the scenario.
Domain 5 doesn't exist in isolation. The screens used during workflow transitions connect directly to Domain 6: Workflows and Automation, and project-level scheme assignment is closely tied to Domain 4: General Project Configuration. Building your understanding across these boundaries will strengthen your performance across roughly 35-45% of the exam's total question weight.
A Focused Preparation Plan for Domain 5
Because Domain 5 is heavily scenario-based, passive reading of documentation is insufficient. The following structure prioritizes active configuration practice, which is what the exam rewards.
Issue Types and Custom Field Contexts
- Create a test Jira Cloud project; build two custom issue type schemes and swap them on the project
- Create three custom fields with different types (select, date, user picker); configure a global context on one, a project-specific context on another, and an issue-type-specific context on the third
- Verify in each project which fields appear and which don't - note what happens vs. what you expected
- Review Atlassian's documentation on custom field contexts and option configuration
Screens, Screen Schemes, and Field Configuration Schemes
- Build a new screen, add it to a new screen scheme as the Create screen only, assign to an issue type screen scheme
- Configure a field configuration: make one field required, hide another, change a renderer
- Practice the diagnostic sequence: when a field is missing, check context → screen → field configuration in that order
- Work through ACP-120 practice test questions specifically on scheme interactions before moving on
This two-week focus on Domain 5 fits naturally within a broader study plan. The ACP-120 Study Guide 2026: How to Pass on Your First Attempt provides a full preparation framework that situates Domain 5 alongside the other seven domains in a realistic schedule. If you're weighing whether the time investment is worthwhile, the Is the ACP-120 Certification Worth It? Complete ROI Analysis 2026 examines the career and compensation implications of earning the credential.
When you're ready to test your Domain 5 knowledge under exam conditions, our full ACP-120 practice test platform includes scenario-based questions that mirror the configuration-reasoning format of the actual Certiverse exam.
Frequently Asked Questions
A screen controls which fields are visible to users during a specific operation (Create, Edit, or Transition). A field configuration controls field behavior - whether a field is required, hidden, or uses a specific renderer. Both must be configured correctly for a field to appear and behave as intended. A field hidden in a field configuration will not display even if it's present on the screen.
The ACP-120 has up to 75 questions and Domain 5 covers 15-20% of the exam. That translates to roughly 11-15 questions focused on issue types, fields, and screens. Because many of these are scenario-based configuration questions, each one typically requires multi-step reasoning rather than simple recall.
Yes - this is one of the most commonly tested concepts in Domain 5. When you modify a shared scheme (adding or removing issue types, reordering options), every project associated with that scheme is immediately affected. If you need to change behavior for only one project, you should either create a new project-specific scheme or copy the existing scheme, modify the copy, and reassign only that project.
Yes - this is exactly what multiple field contexts enable. You create separate contexts for different sets of projects (or issue types), and each context can have its own distinct list of select options and its own default value. This is the correct approach rather than creating separate duplicate fields for each team or project.
No - team-managed (formerly next-gen) projects have a simplified, project-local configuration model. They do not use the global scheme hierarchy of issue type schemes, field configuration schemes, or issue type screen schemes in the same way. The ACP-120 focuses predominantly on company-managed project administration, but you should understand the distinction because exam questions may test when each project type is appropriate.
Ready to Start Practicing?
Domain 5 scenario questions require genuine configuration reasoning - not just memorization. Test your understanding of issue types, custom field contexts, screens, and scheme interactions with our ACP-120-specific practice tests, built to match the format and difficulty of the Certiverse exam.
Start Free Practice Test- ACP-120 Study Guide 2026: How to Pass on Your First Attempt
- ACP-120 Domain 1: User Features (10-15%) - Complete Study Guide 2026
- ACP-120 Domain 2: Configuring Global Settings and User Communications (5-10%) - Complete Study Guide 2026
- ACP-120 Domain 3: Product and Project Access and Permissions (30-35%) - Complete Study Guide 2026