Skip to main content

Views

Views are reusable configurations of UI elements that define how information is presented to users and how they interact with it. Views are key building blocks of an application and are used to collect and display information. By organizing Fields and other UI components into clear, structured layouts, Views make it easier to capture, review, and understand data as work progresses. Rather than focusing on technical screen design, Views allow you to specify what information users need to see and when, enabling Pega to deliver a consistent and responsive user experience across different contexts.

The following image shows a nearly completed View meant for collecting customer information:

Image showing typical view of contact info collection fields

Views use predefined patterns and UI components to create a cohesive and intuitive experience. Within a View, you add relevant fields so users can view existing information or enter new data. Each field name and user‑entered value is stored as a data element, making the information reusable throughout the application. These data elements can be presented for editing or displayed as read‑only, depending on how the information is intended to be used.

For example, a loan application might include separate Views that allow applicants to enter their personal details, loan information, and relevant financial data. The same application can provide a different View for an internal loan officer, where the applicant’s information is displayed as read‑only Fields and the loan officer records an approval or rejection decision using editable Fields.

Note: Views that gather information from a user are often referred to as forms. A special type of form called a Multi-step Form exists that captures many fields into multiple focused and concise Views. To learn more about Multi-step Forms, see Form Views.

Views for specific Tasks

Consider a Process for making loans. In this example, there are two Steps:

  1. The first Step in the Process requires customers to enter information for a loan application. The form contains fields for entering information such as the customer's name, the loan amount, and the loan type. After customers complete the form, the system sends the request to loan officers for review:
    Loan application form

  2. In the second Step of the Process, loan officers have a Loan officer View that displays the collected data. Loan officers can read but cannot update the customer's information. The Loan officer View contains fields for officers to enter information such as loan insurance qualification and approval reason:
    Loan application View

View considerations

When designing Views, you decide what information users need to see or enter to complete their work. For example, a mileage or incident reporting application might include a View that allows drivers to quickly report minor windshield damage caused during transit. To ensure an effective user experience, several design decisions must be considered, such as which fields to include, the type of values users enter, and the order in which the fields appear. You also determine whether fields should be editable or read‑only, visible or hidden, and required or optional.

The following image of a Report problem View shows one example of many possibilities when these questions are answered:

Image showing a Report problem view with request date, full name, issue severity and description fields.

Check your knowledge with the following interaction:

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 user input and processing work.  A form is a type of View, but not all Views are forms. For example, in a customer service scenario for reporting incidents, the user enters personal and contact information when submitting a request. A form collects the customer's first name, last name, email, phone number, and the method to provide the address. A View can also display a read-only summary or confirmation of the reported incident after submission. Forms typically include standard action controls, such as buttons to submit, cancel, or navigate through the form, to guide users as they enter and review information.

The following image shows the completed interaction from the first section of this topic; in the first View, which functions as a form, a radio button field conditionally displays the second View based on user input:

Image with callouts showing multiple Views and a condition
Note: For detailed information on Views, see Working with Views

Check your knowledge with the following interaction: 


This Topic is available in the following Modules:

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