Skip to main content

Views in Constellation

You use Views to collect and display information that is relevant to Case resolution.

Users interact with your applications by using Views. Views are the interface for each assignment in the Case Lifecycle and each data object. The forms that collect user information, tables that display list data, and read-only tabs that make primary information readily accessible are all examples of Views.

You can populate Views with UI elements, such as text fields, checkboxes, lists, and other Views. The selection of UI elements that are available for you to populate your Views is determined by your Data Model. It is essential to correctly configure your Data Model before you configure the Views.

The four types of Views

There are four primary types of Views in Constellation applications:

View

Description

Editability

Full Page View

The main interface in which the user processes Case work or accesses information about a data object. The system creates one Full Page View for each Case or data object.

Read-only

Partial View

A View that you create for a specific Case or object to display data. These Views include custom Views that you create during application development and default Views that the application creates, namely the Details and Preview Views. When enabled, the Confirmation View also appears in the Case Views list.

Read-only

List View

A View that relies on a data source. Depending on the configuration, the system can display lists as tables, timelines, or tile-based galleries. By default, every Case includes a list that contains open Cases and a list that contains Primary Fields.

Data objects do not support the timeline View.

 

Read-only

Form View

A View that the user interacts with when working on the Case. The system creates a form View for each Step in the workflow when you configure Views from the Workflow tab. The Create and Edit Views appear automatically in the Form list. The Create view represents the opening form of your application, and the Edit view represents the form that is connected to the edit button in the Case header. The form list also includes the default Case history list View. Form Views use the default form template or simple column templates.

Editable and read-only

Views versus forms

A View is a reusable configuration of UI elements that you can use to interact with a Case. A form is a reusable interface for collecting data from users and processing work.  A form is a type of View, but not all Views are forms. Both Views and forms can have embedded Views to design a modular, reusable UI.

For example, in an online shopping website, the customer needs to enter personal information and shipping information when placing their online order. Match the numbers to the following image to learn more about how Forms, Views, and fields work together to create an interactive web page for a online order Case:

  1. View in navigation: The navigation pane is configurable with Views, where the customer can see different navigation menu options.
  2. Personal information: In the personal information View, the customer can enter personal details.
  3. Shipping information: In the shipping information View, the customer can enter the shipping address.
  4. Form: The form is used to collect the customer's personal information and shipping address using two embedded Views. A form can have multiple Views, fields, and buttons. Forms are preconfigured with buttons like Cancel, Next, Previous, and Submit.
Regions of a Form

The same personal information and shipping address Views can be reused to display a read-only order confirmation with the contents of the user's purchase and their order total once the transaction is completed.

Designing Views

Views can be created for both data objects and Cases.

Data object Views

Views for the data object can be constructed with fields from the data object and other Views created for the Data object. By default, Data object Views are read-only.

When a data object is associated with a Case Type through a data relationship, the Case Type has access to all of the fields and Views associated with that data object.

Case Views

You can create a Case View using any of the View types. By default, Pega Platform™ generates a Form View for each Step in the Case, excluding Automation Steps where Views are not relevant. The name of the View is the same as the name of the Step.

Tip: As a best practice, build Views from the lowest embedded level upwards. For example, when you want to reuse fields, the best practice is to embed those fields in a View created directly in the target class. For the View maintenance perspective, embedding Views is preferable to embedding fields.

Design for reuse

In Pega Platform, Views are reusable configurations of UI elements that allow you to build modular and consistent spaces for completing Assignments with less effort. They are key building blocks of your application and are used to both collect and display information to the user. 

Views are reusable across multiple Case Types. For example, a View that displays information about a retail product Data Object, including fields such as Product name, Description, SKU, and Price, can apply to Views across an array of sales and distribution Case Types for a manufacturing company.

Preview and stakeholder validation

Pega Blueprint™ contains a preview capability that is invaluable during stakeholder reviews. With a click, Blueprint generates an interactive preview of the application. Stakeholders can see the customer journey, test the flow, and experience the interface before any implementation begins. For example, a Solution Designer can show U+ Bank stakeholders what the application will look like and make requested changes in Blueprint immediately, so stakeholders can see the update in real time.

The application preview in Blueprint showcases Constellation's responsive design capabilities, demonstrating how Constellation will automatically adapt the user interface from desktop to mobile, without requiring separate interfaces for each channel or device. This iterative design process, enabled by Blueprint's preview feature, means that stakeholders approve the direction with confidence before a developer begins implementation on their Pega application.

Check your knowledge with the following interaction:


This Topic is available in the following Module:

If you are having problems with your training, please review the Pega Academy Support FAQs.

Did you find this content helpful?

Want to help us improve this content?

We'd prefer it if you saw us at our best.

Pega Academy has detected you are using a browser which may prevent you from experiencing the site as intended. To improve your experience, please update your browser.

Close Deprecation Notice