6.2 Views, Dynamic Layouts, Design Templates & Action Sets

Views, Dynamic Layouts, Design Templates & Action Sets

User interface design in the Pega Platform centers on building intuitive, responsive, and reusable experiences for both operational workers and external customers. Pega provides a structured continuum of UI authoring capabilities: from high-level, low-code Views and region-based Design Templates in App Studio to granular Dynamic Layouts, Repeating Dynamic Layouts, and event-driven Action Sets in Dev Studio.

For a Certified System Architect (CSA), mastering how these visual components operate—and knowing when to configure them in App Studio versus Dev Studio—is critical for building scalable applications that comply with Pega guardrails.

---

1. Views in App Studio: Low-Code Form Design

In modern Pega applications, a View represents the visual layout and data collection interface presented to users during a specific stage or step of a case lifecycle. Views abstract away low-level HTML markup, allowing Business Architects and System Architects to configure screens declaratively.

Types of Views

Pega categorizes views based on their operational context within the case lifecycle:

1. Form Views (Data Capture Views):
   • Configured directly on Collect Information steps within the Case Designer.
   • Designed to capture user input, display guidance instructions, and guide the user through completing an assignment.
   • Fields can be marked as Required, Optional, or Read-Only based on business needs.
2. Summary Views (Overview Panels):
   • Typically configured for the summary panel of a case (such as the left or right preview pane in Theme Cosmos / Constellation).
   • Presents critical case metadata at a glance—such as Case ID, Priority, Urgency, Primary Contact, Status (pyStatusWork), and Creation Date—without requiring the user to open individual assignments.
3. Detail Views (Object-Level Views):
   • Associated with specific Data Objects (such as Customer, Address, or Vehicle).
   • Detail views allow a data entity to define its own standard presentation. When that data object is embedded into a case type, its detail view can be reused directly, eliminating the need to recreate identical field groupings across multiple forms.

View Reusability Across the Case Lifecycle

Pega enforces the principle of reuse through view management:

• Rather than constructing a new view for every step from scratch, architects can select Reuse an existing view.
• For instance, a ReviewPolicyDetails step in an underwriting stage can reuse the exact view authored for the EnterPolicyDetails step in the submission stage, simply configuring the step to display the fields in Read-Only mode.
• Changes made to a shared view automatically propagate across all steps referencing that view, dramatically lowering maintenance overhead.

---

2. Reusable Design Templates: Region-Based Composition

A Design Template is a predefined structural framework that governs how fields and UI components are organized visually on the screen. Rather than manually positioning elements on an arbitrary freeform grid, architects use design templates to maintain strict visual consistency across an enterprise application.

The Region (Slot) Architecture

Design templates operate using a region-based composition model. Pega's Constellation DX layout templates "provide slots called Regions", and region is the name the exam uses:

• The template defines the structural layout and exposes designated named placeholders called Regions. Pega's standard region names are Primary (the main data of the layout), Title, Metadata, Actions, Breadcrumbs, and Widget; any region without a specific purpose is named with a letter — Region A, Region B, Region C.
• Architects drag fields, field groups, data objects, embedded sub-views, insights, and widgets into these regions within App Studio.
• The template controls the spacing, alignment, responsive wrapping, and visual hierarchy of the region contents according to enterprise design standards. Because fields stay in their named region, using the standard region names is what makes switching a view from one template to another reliable.

Common Standard Design Templates

• 1-Column Template: Stacks all fields vertically in a single column. Ideal for linear, mobile-friendly forms, simple checkout steps, or quick data verification screens.
• 2-Column Template (Equal 50/50 Split): Splits the form into two balanced columns. Best for comparing parallel datasets (e.g., Billing Address vs. Shipping Address).
• 2-Column Template (Asymmetric 70/30 or 60/40 Split): Provides a dominant primary work area on the left (70%) for primary data entry, flanked by a narrower utility/context panel on the right (30%) for reference data, calculations, or help text.
• 3-Column Template: Distributes content across three balanced columns. Suited for wide desktop dashboard views or dense financial summary screens.
• Tabbed Template: Organizes complex datasets into horizontal tabs (e.g., Customer Info, Financial History, Documents), allowing operators to navigate multifaceted cases without vertical scrolling.
• Accordion Template: Organizes information into vertically stacked expandable/collapsible panels. Ideal for multi-step reference data where users inspect one section at a time.

---

3. Dynamic Layouts in Dev Studio (Traditional UI)

In Traditional UI development within Dev Studio, the Dynamic Layout is the primary structural building block of Section rules (Rule-HTML-Section). Dynamic layouts provide responsive, device-agnostic presentation without requiring hardcoded table tags or manual pixel dimensions.

Dynamic Layout Formats

Pega provides four standard Dynamic Layout formats, each optimized for specific visual requirements:

+-------------------------------------------------------------------------+
|                       DYNAMIC LAYOUT FORMATS                            |
+-------------------------------------------------------------------------+
| 1. STACKED LAYOUT:                                                      |
|    [ Field Label 1 ]                                                    |
|    [ Input Control 1                                          ]         |
|    [ Field Label 2 ]                                                    |
|    [ Input Control 2                                          ]         |
|    (Each label and control pair occupies its own full-width row)        |
+-------------------------------------------------------------------------+
| 2. INLINE LAYOUT:                                                       |
|    [Label 1] [Control 1]   [Label 2] [Control 2]   [Label 3] [Control 3]|
|    (Items flow horizontally on the same line, wrapping as needed)       |
+-------------------------------------------------------------------------+
| 3. INLINE-GRID LAYOUT:                                                  |
|    [ Col 1: Label + Ctrl ]  [ Col 2: Label + Ctrl ]  [ Col 3: Label... ]|
|    [ Col 1: Label + Ctrl ]  [ Col 2: Label + Ctrl ]  [ Col 3: Label... ]|
|    (Fixed-width multi-column grid maintaining strict vertical alignment)|
+-------------------------------------------------------------------------+
| 4. DEFAULT LAYOUT:                                                      |
|    Inherits standard label-above or label-left alignments from Skin     |
+-------------------------------------------------------------------------+

1. Stacked: Arranges fields vertically. Each label and control pair occupies a full-width line. This format is the most responsive and is recommended for mobile forms and narrow sidebars.
2. Inline: Places fields side-by-side on a single horizontal line. When the browser window shrinks, elements naturally flow to the next line like words in a paragraph. Commonly used for search bars with an adjacent search button.
3. Inline-Grid: Displays fields in a structured multi-column grid (e.g., 2, 3, or 4 columns) where items maintain strict vertical and horizontal alignment. When screen width drops below designated responsive breakpoints, columns automatically wrap to preserve readability.
4. Default: Applies platform-default styling inherited from the application Skin rule, typically aligning labels to the left of controls or above controls based on skin settings.

Responsive Breakpoints and Layout Wrapping

Dynamic layouts integrate directly with the application Skin rule (Rule-PortalSkin). Skins define Responsive Breakpoints (e.g., Large Desktop > 1200px, Tablet 768px–1199px, Mobile < 768px). When a user resizes their browser or accesses the case from a smartphone, dynamic layouts automatically adapt:

• Inline-grid columns collapse from 4 columns to 2 columns, and ultimately to a single stacked column on mobile displays.
• Non-essential UI elements can be conditionally hidden on narrow viewports to preserve screen real estate.

---

4. Repeating Dynamic Layouts (RDL) & Table Layouts

Enterprise applications frequently manage collections of records—such as a list of dependants, line items on an invoice, or medical test results. Pega utilizes Repeating Dynamic Layouts (RDL) and Table (Grid) Layouts to render these collections.

Repeating Dynamic Layouts (RDL)

• Binds directly to a Page List or Page Group property on the Clipboard (e.g., .Dependents or .InvoiceLines).
• The RDL acts as an iterator: it takes a single section template and dynamically stamps it out once for every page element present in the collection.
• RDLs provide great visual flexibility, enabling card-based layouts, tile matrices, or custom record banners that adapt gracefully to different screen sizes.

Table / Grid Layouts

• The standard mechanism for presenting high-volume tabular data.
• Sorting & Filtering: Enables end users to click column headers to sort ascending/descending and apply text or value-based filters directly in the browser.
• Pagination: Handles large datasets by configuring pagination modes (e.g., Page 1 of 5, First/Last Page, or Progressive Scroll / Virtualization), preventing browser memory overload.
• Responsive Column Dropping (Priority Column Display): Developers assign priority levels to table columns (Primary, Secondary, Low). On smaller tablet or mobile screens, the table automatically hides lower-priority columns, keeping only essential columns visible while offering an expandable row drawer to inspect hidden details.

---

5. Action Sets: Event-Action-Target Architecture

In Traditional UI, dynamic client-side interactivity is implemented using Action Sets. An Action Set defines what happens when an operator interacts with a UI control.

+-------------------------------------------------------------------------+
|                  ACTION SET ARCHITECTURE (EVENT -> ACTION)              |
+-------------------------------------------------------------------------+
| 1. EVENT: What user action triggers the processing?                    |
|    - Click, Change, Hover, Double Click, Key Down                       |
+-------------------------------------------------------------------------+
                                    |
                                    v
| 2. CONDITIONS (OPTIONAL): Should the action execute?                    |
|    - When Rule evaluation (e.g., IsVIPCustomer, HasSelectedOther)       |
+-------------------------------------------------------------------------+
                                    |
                                    v
| 3. ACTIONS & TARGET: What operations execute, and on what target?       |
|    - Set Value: Updates a target property locally                       |
|    - Run Data Transform: Executes server-side data manipulation         |
|    - Post Value: Transmits field data to server Clipboard               |
|    - Refresh Section: Reloads designated section with fresh server HTML |
|    - Show Harness / Launch Harness: Navigates or displays a popup       |
+-------------------------------------------------------------------------+

The Three Components of an Action Set

1. Event: The trigger initiated by the user.
   • Click: User clicks a button, link, or checkbox.
   • Change: User modifies a text box, selects a dropdown option, or toggles a radio button and blurs focus.
   • Hover: User moves the cursor over an icon or link (often used to display contextual cards).
   • Double Click: User rapidly clicks twice on an element (common in grid row selection).
2. Action: The operational task executed when the event fires.
   • Set value: Directly copies a static literal or property value into a target property.
   • Run Data Transform: Executes a specified Data Transform on the server to update multiple properties or recalculate totals.
   • Post value: Asynchronously pushes the control's current value to the server Clipboard without reloading the UI.
   • Refresh Section: Calls the server to re-render the section, optionally executing a pre-activity or data transform before generating new markup.
   • Show Harness / Run Flow / Open URL: Navigates the user to a different portal, case step, or external web link.
3. Conditions (When Rules):
   • Each action within an action set can be gated by a When condition (Rule-Obj-When).
   • If the condition evaluates to true, the action fires; if false, the action is skipped.

---

6. Form Presentation & UX Best Practices

Pega provides specific design guidelines to maximize user productivity and minimize cognitive fatigue:

1. Progressive Disclosure:
   • Avoid overwhelming users with cluttered forms containing dozens of fields that may not apply.
   • Use Conditional Visibility (driven by When rules or expression logic) to dynamically reveal secondary fields only when relevant (e.g., revealing an Explanation of Damage text area only if the user checks Has Existing Damage).
2. Logical Field Grouping:
   • Cluster related properties into distinct visual containers or sub-sections with clear headers (e.g., Personal Information, Contact Preferences, Coverage Options).
3. Instruction Text vs. Helper Text vs. Tooltips:
   • Instruction Text: Placed at the top of a form or stage to explain the overarching business goal of the assignment.
   • Helper Text: Persistent explanatory text rendered directly beneath an input control to clarify formatting expectations (e.g., "Include country code, e.g., +1 555-0100").
   • Tooltips: Transient hover text used sparingly for supplementary context without cluttering the screen layout.

---

7. Full Page Views and Case Tabs

A form view is what a user fills in during an assignment. The Full Page View — also called the Full Case View — is different: it represents a single case in its entirety, and it is what a user sees when they open the case rather than work a step.

The Three-Pane Layout

The Full Page View uses a three-pane layout designed to accommodate a large amount of case information, much of which is visible without scrolling or navigating to another view. In practice that means the summary, the primary case content, and supporting context can all be on screen at once, which is why it is the default surface for reviewing a case.

Customizing It

You edit the Full Page View on the UX tab of the case type or data object. The elements associated with the Full Page View are grouped on the Full Page View tab there. That is the answer to a scenario that says "the case overview screen must show different content" — it is a configuration on the case type's UX tab, not a new harness rule and never custom markup.

Case Tabs

Within a case view, you can group fields by category using a tabbed view template. Tabs create an intuitive interface that saves screen space and helps users find information with fewer clicks. Note the distinction from Section 6.4: a hierarchical form uses tabs (form groups) inside an assignment form, while case tabs organize content inside the case view. The mechanism rhymes; the surface is different.

What to Recognize on the Exam