6.4 Form Views: Default vs Hierarchical Forms, Field Groups & Primary Fields
Key Takeaways
- A default form presents all of an assignment's fields in one continuous layout, while a hierarchical form splits the same fields across tabs, where each tab is called a form group.
- Constellation form layouts support one to three columns; a two-column layout is Pega's recommended default for most assignment forms.
- A field group clusters related fields under a single header inside a view, can be collapsible, and can carry instructions for the user.
- Primary fields let Pega automatically place the most relevant case fields into the generated Primary Fields view, which is added to the Create, Edit, and Details views.
- Choose a hierarchical form when one assignment captures many fields across distinct subjects; choose a default form when the field count is small enough to complete without excessive scrolling.
6.4 Form Views: Default vs Hierarchical Forms, Field Groups & Primary Fields
Section 6.2 covered where views live and how design templates assemble them. This section covers the shape of the form itself — the specific configuration choices the official User Experience objectives call out by name: default versus hierarchical forms, field settings, primary fields, and field groups.
1. Form Views and Column Layout
A form view is the view attached to an assignment step. It is what the user actually fills in. When you configure a form layout you choose how many columns the form uses.
- Constellation forms support one, two, or three columns.
- Pega's published guidance is to use a two-column layout for most use cases. One column suits very short forms and narrow viewports; three columns crowd most business forms and hurt scanability.
Column count is a layout decision, not a data decision. It does not change which fields are captured — only how densely they are presented.
2. Default Forms vs Hierarchical Forms
This is the comparison the blueprint names explicitly.
| Default form | Hierarchical form | |
|---|---|---|
| Structure | One continuous form region containing all fields | Fields split across tabs; each tab is a form group |
| Navigation | Vertical scrolling | Tab selection within a single form view |
| Best for | Short to moderate assignments — a handful of related fields | Long assignments that span several distinct subjects |
| Configuration | Default template; add fields and field groups directly | Select the Hierarchical form template, define form groups, then configure each group's fields |
| User effect | Everything visible in one pass | Reduces scrolling and reserves the window area for the fields currently in focus |
A hierarchical form divides a complex assignment that captures data across many fields into smaller, related groups of fields, reducing scrolling and making better use of the window during case processing. Each tab is a form group, so the mental model is "one assignment, several subject tabs," not "several assignments."
Worked Example
A commercial insurance underwriting assignment captures 40 fields: applicant identity, property characteristics, prior loss history, coverage selections, and broker details. A default form would produce a single scrolling wall of inputs.
Configured as a hierarchical form, the same assignment becomes five form groups — Applicant, Property, Loss history, Coverage, Broker — each surfaced as a tab. The underwriter still submits one assignment, and validation still applies across the whole form, but the cognitive load per screen drops sharply.
The Judgment Call
- Do not split a six-field form into three tabs. Tabs add navigation cost that short forms do not repay.
- Do not solve a long form by breaking it into three separate assignments unless the business genuinely wants three separate units of work with separate routing, SLAs, and audit points. Splitting assignments changes the process; splitting into form groups changes only the presentation.
3. Field Groups
A field group is a cluster of individual fields that together present related data inside a view. The fields can come from the case type data model or from data objects referenced by the case.
Field groups give you three capabilities that loose fields do not:
- A shared header — the group carries its own label, so related fields read as a unit.
- Instructions — you can attach guidance text to the group, which is where step-level help belongs instead of stuffing it into individual field labels.
- Collapsible sections — a group can be collapsed so rarely used fields stay out of the way without being removed from the form.
Field groups work inside both default and hierarchical forms. In a hierarchical form, a single tab (form group) commonly contains two or three field groups.
4. Primary Fields
Primary fields are a labor-saving configuration, not a new UI construct. You designate which fields of a case type are the most relevant ones, and Pega Platform automatically generates a Primary Fields view and adds it to the Create, Edit, and Details views.
The benefit is that the three views most applications need for every case type stop being three hand-built configurations. You mark the fields once, and the generated view keeps those three surfaces consistent as the data model evolves.
Exam framing: when a scenario says "the same handful of fields must appear when a user creates the case, edits it, and views its details, and the team wants to avoid maintaining three views," the answer is primary fields, not three manually authored views.
5. Field Settings
Field settings control how a single field behaves inside a view. The settings the exam expects you to recognize:
| Setting | Effect | Guardrail note |
|---|---|---|
| Required | User cannot submit the form without a value | Prefer the field setting over an activity that checks for blanks |
| Read-only | Value is displayed but not editable | Common for values sourced from a data page or a system of record |
| Editable / Read-only when | Conditional editability driven by a when rule or expression | Keeps logic declarative and reusable |
| Visibility conditions | Show or hide the field based on case data | The core mechanism behind dynamic forms |
| Label and instructions | Display text and inline guidance | Localizable through field value rules |
Adding and removing fields is done in the view configuration itself: adding a field to a view does not create a data model field unless you choose to create one, and removing a field from a view does not delete the underlying case data. That distinction is a frequent exam trap — removing a field from a form leaves existing case data intact.
6. How These Choices Fit Together
A well-built assignment view for a data-heavy case type typically layers all four constructs: a hierarchical form provides the tabs, each tab holds one or two field groups, individual field settings drive required and conditional behavior, and primary fields keep the Create, Edit, and Details views synchronized without extra authoring.
An onboarding assignment captures 38 fields covering personal details, employment history, tax elections, and equipment requests. Users complain about endless scrolling, but the business insists it is still one unit of work with one SLA. What is the appropriate Constellation configuration?
A team must display the same six key fields on the Create, Edit, and Details views of a case type, and wants those three surfaces to stay consistent as the data model changes. Which configuration meets the requirement with the least ongoing maintenance?
A business architect removes an unused field from a Details view, then asks whether the historical values captured in that field on 4,000 existing cases have been deleted. What is the correct answer, and what is Pega's published guidance on column count for the form that remains?