When you start building a house, the most important thing is to have a good foundation; the same happens with the pega application. We designed the class structure based on the business; for example, a banking company has many divisions, such as personal loans, credits, onboarding. etc. If we build everything under the same class structure, it will be impossible to maintain. This is where class hierarchy comes to save the day, because instead of having all your assets under one layer, you can distribute them within the class structure and take advantage of rule reusability.
Pega Platform™ enables you to organize your application by using the same dimensions as your business. Pega Platform makes reusing common policies and procedures easy while allowing for differences between products, regions, channels, and customer segments.
In the following diagram, I explain the Class hierarchy structure and you will find some examples of rules and assets that each class can have, as well the definition of each class.
1. Pega Platform Layer: The Pega Platform Layer contains the built-in assets that are necessary for processing Cases and other work in Pega Platform applications. This Layer also includes the assets that Pega Platform uses.
2. Organization Layer: The Organization Layer contains the assets that are used on an enterprise-wide basis. For example, access to an external customer database is an integration point that you can add to the Organization Layer.
3. Division Layer: The Division Layer is optional and contains assets used on a division-wide basis. Assets in the Division Layer may apply to a line of business, region, or brand. For example, you save a Service-Level Agreement (SLA) Rule that defines the expected response time to a customer complaint in the Division Layer to enable all applications within that division to use that SLA Rule.
4. Unit Layer: If you enable the Division Layer, you can optionally enable the Unit Layer, which contains assets that are used on a unit-wide basis.
5. Implementation Layer: The Implementation Layer contains one or more applications customized for a specific division or line of business. For example, a clothing retailer consists of two brands of stores. Each brand can create its own Implementation Layer for brand-specific assets, such as styling and policies.
Class inheritance
Classes in pega are used to organize rules, so when in comes enterprise class structure you have to think about each class as a layer that contains assets for your organization, each layer has rules that can be reused trough inheritance
Types of class inheritance
Pattern inheritance: this type of inheritance is like a family tree, you got one parent class and then it started to get child classes, each child class is defined after the parent class with a hyphen, for example we have the parent class MyOrg-KnowYour-Work, then we create a child case class -GlobalKYCCustomer,
GlobalKYCCustomer can access assets form
↓
Work
↓
KnowYour
↓
MyOrg
↓
@baseclass
so basically if you need to create a rule that will be reuse trough your organization, you can create it at the level of KnowYour on that way you can ensure rule reuse and can be accessed at any child level or integration level
–Direct inheritance: this is way different than pattern inheritance, with direct inheritance you create a class and then you define the parent class in the class inheritance tab. It lets an application reuse standard Pega Platform rules (such as Work- or Data- classes) or rules from built-on framework applications.
there is a way to check the inheritance of a class, you can goo to the app app explorer, locate the target class, right click on the class and there is an option that say Inheritance
Then a windows will pop up and you can check the pattern and the direct inheritance that the class may have
Questionnaire
An application uses three Layers in its Class hierarchy structure. Drag the Layer name on the left to its correct description on the right.?
You have a requirement to create an email Correspondence that built-on applications can reuse. In which two Layers of the Class hierarchy structure could you apply the email Correspondence Rule? (Choose Two)
Division
Pega Platform™
implementation
organization
Answer : 1. Division and 4. Organization
3. What is the purpose of the Class hierarchy structure?
Answer: It provides a structure that supports Rule reuse.
The Modular Applications and Reusable Features approach is similar to working with classes and functions in traditional programming languages.
In this approach:
A module is similar to a class
A feature is similar to a function
A module is a built-on application that contains processes, flows, decisions, data pages, views, and other reusable rules that address a specific business, integration, or utility use case.
You can find more information about this topic in the Module Best Practices course on the Pega Academy website.
When designing a module, it is very important to keep in mind that the module cannot depend on any specific part of the application. It must be self-contained and reusable across different flows, case types, or applications within the organization.
Generally, a module is related to an entity in your case model. For example, Customer could be implemented as a module.
But how can you determine whether something should be a module?
You should analyze the following questions:
Is it transparent?
Can it be encapsulated?
Is it largely self-documenting?
Is it easy to consume?
Can it be parameterized?
Does it provide appropriate flexibility?
Is it App Studio–friendly?
The main goal of a module is reusability. No matter which case type or application uses it, the module should work independently and be fully parameterized to support different scenarios.
This means that modular applications should not contain business-specific logic, case types, or UI views. Instead, they should contain reusable features.
What are the features in Pega?
Features in Pega Platform work similarly to functions in programming languages.
A feature:
Receives parameters
Processes information
Returns an output
Examples of features include:
Integration with external APIs
Business logic evaluation
Data retrieval services
Utility processes
It is very important that a feature can work in any application within the organization. This means it must not depend on specific case types, flows, regions, or divisions..
How to build modular applications in pega?
THow to Build Modular Applications in Pega
To build modular applications in Pega Platform, we need to define the application class structure and data model.
Let’s break the process into simple steps.
Step 1: Define the Modular Situational Layer Cake
This design pattern helps organize applications into reusable layers.
The module application should not contain case types. Instead, it should contain reusable processes that function as features.
These features can then be reused anywhere within the organization.
Let’s imagine we are designing an Onboarding application for a banking institution.
We will organize our architecture using the following layers.
Pega platform
This is the base layer of the class hierarchy.It contains all out-of-the-box rules provided by the Pega Platform, including assets required to run and automate the application.
Enterprise
This layer contains assets reusable across the entire organization.
Examples include:
Shared data types
Common integrations
Shared utilities
Example:
A Contact data type that contains:
phone number
address
email
contact details
This data type can be reused across multiple entities such as:
Related party
Customer
Stakeholder
Module layers
This layer contains the modular applications.
These modules are not part of the class inheritance hierarchy.
Instead, they are added to the Built-On Applications section of an application’s definition.
This allows the business application to reuse all the rules, features, and data objects from the module.
Business applications layer
This layer will contains the application that will have the business logic, case types, validations, stages, process, etc.. all the assets necessary for that application to run, for example on this layer We will define the onboarding application that will contains the case type to onboard a customer we can called it journey, the forms and steps to get all the data, and then we can call the features from the modules to get some information about our customer, generally since the modular application is already added to the built on applications in the onboarding app, this will get access to all the features for the customer module application and to his data objects.
Step 2: Data model design
This step is very important because we want to make sure that all data could be reusable for all the modules, is very important that all stakeholders gets involved in this two steps to align all departments with the business requirements.
object oriented data model, another important point is that in constellation, views are created on the data objects for example you have a form that request all the information about the costumer, this form will be on a view, this view must be on the customer data type to access all his data, doing that you will have the form view in the modular application that can be reused in any application whit in the organization.
there are couple of tools that will help you to design the data model I personally use drawio because is free and very easy to use, at work we use Visio that is a good choice if you have the license because you can design a large data model and can export it I high resolution.
I will give you an example below of a data model design even though there are not complete but it gives you the idea of what you need to accomplished on this stage.
since you already create the customer module you need a data object for that module, in the picture above show a table called customer that will represent the data type for customer in Pega, customer will have some attributes such as Name, Last Name, Accounts.. etc, all the information that we are going to use in forms, features, etc.. must be on customer. then we create a separate table called contact, in this data type we encapsulated the address, phones, emails all the contact information.
We are going to create de contact data type in a enterprise layer, this is because we identify that the contact information can be reused not only in customer, it can be reused in any other application or module that requires this information, lets say that you are building a stakeholder case, and need to capture the contact information, since we create this data object in the enterprise layer, you can create a field on the data object of stakeholder and reference the contact data, with that you will also have access to de views.
Step 3: Identify and Design the features
on this stage you have to identify the features that are necessary for each module, for example if you have the requirement to create an integration that you will send the id of the customer and it will return all the information of the customer if its finds it and if not you will get a response that says customer not found.
So at this point we can identify if it can be a feature because it will receive information, process this information and returns a response, ok where do we put this feature in which module?, since we send information about the customer and receive information about the customer, this feature will need access to the customer data object so consequently it needs to be on the customer module. and that’s how you can define where to create the feature analizing the data that the feature will need and what is the purpose of this feature.
So you can create a miro (is an application that is like a board that you can create bunch of stuff I think is free) with all the stakeholders and start designing all the feature for each module, something that we used to do in this stage is, list all the possible features, lists all the possible modules, and then
the picture above could be an example of the very first stage of designing the features per module, you can listed and just give a brief explanation of what this would do. then when you have all the features already identified you can start designing you case types and journeys.
Step 4 : Create a feature
To create a feature you have to take in mind that will be a process, this process will return some data or do some work in your case type. this feature could be an integration with an API, it could be a data transform that evaluates some business logic and return a response.
To be reusable in any application is necessary that doesn’t depend on any other feature or module, one very important point to take into consideration is the data that the feature needs I has to be created on the module where this feature lives, or any common layer that any application can reference to.
Another Important point is that you have to mark as relevant the process of the feature, this is to be visible on app studio and you can integrate it to the application.
this is what a feature may look like in the design phase
In Pega you will have a process that will call an activity lets called Invokeweatherservice, this activity will be on charge to create the params that the service needs , invoke the service and then returns a response, then on the activity get that response and mapped back to the case
Recap
Create you modular application for this example I created customer:
Create customer data model, I created using the ai from Pega and automatically create all the fields I need it
Crate the feature this feature could be an api, exernal service etc. create a flow and inside this flow call your logic. is very important that mark this flow as a relevant record
Invoke Customer application in business application for this example I will call it form the application KYC
add the feature to your case type, click on new process and then create a new process such as getCustomerFeature, then click on add process, since we already marked as a relevant record it will appears on the list even though we cerated in a different application
and that is how you can create a modular application , features and used in a different application. if you came to the end of it please let a comment below if you have any questions, please like and subscribe , I will post a video explaining all this step by step in the upcoming days, thanks for being here
Welcome back! 👋 In this tutorial, we’ll walk through three essential Pega skills you’ll use in almost any real application:
Importing a CSV file into a Data Type
Searching and displaying records using a Data Page / Data Type
Creating an Auto-Complete field with visibility conditions
Let’s get started.
1. Importing CSV Data into a Pega Data Type
First, open the Data Type you created in a previous lesson. We’ll be importing a CSV file into it—make sure you have your file ready.
Step 1 — Import the CSV
Open the Data Type.
Go to the Records tab.
Click Import and upload your CSV file.
Click Next.
Step 2 — Map Source to Target Properties
Pega will display each column from the CSV. Map each one to the correct target property, for example:
first_name → FirstName
last_name → LastName
(Complete all mappings based on your CSV.)
Step 3 — Configure Import Options
You can choose how Pega updates existing records:
Always update
Update if blank
Update if source is not blank
For this example, select Always update.
Step 4 — Match Existing Records (Optional)
If your Data Type already contains data, you can match rows by a unique ID.
We do not have IDs in this example, so we’ll select FirstName as the match key.
Click Next.
Step 5 — Validate and Import
Give the import a name, then:
Validate the file
Confirm there are no errors
Click Finish
Your Data Type will now show all imported records—hundreds of rows ready to use! This is extremely useful when populating lists such as countries, states, cities, or any reference table.
2. Building the Customer Search Auto-Complete
Now let’s go back to our case flow.
We’ll create the first assignment form where users search for an existing customer. If the customer isn’t found, we’ll later add a button to create one.
Step 1 — Open the Section
Open the Flow Action.
Open the Section rule.
Switch to the Full Section Editor.
This is where we build the customer search UI.
Step 2 — Add an Auto-Complete Field
From the palette, go to Data Capture → Auto Complete.
Drop an auto-complete field on your form.
Set the Target Property (create a new property if needed).
Step 3 — Use a Data Source
Auto-completes can source from:
A data page
A clipboard page
A report definition
A property
Because our customer data is stored in a Data Type, we will use a Data Page List.
⚠️ Important: A Page List Data Page must be used to return multiple results. A single-record Data Page only returns one item based on a parameter, so it won’t work for autocomplete.
Step 4 — Select the Data Page List
Choose the Data Page List created from your Data Type.
Then configure the search results:
Search field:FirstName
Display fields: First Name, Last Name
Identifier:.pyGUID (the unique ID)
Step 5 — Add the Hidden Customer ID Field
Create a property to store the selected ID.
When the user picks a name from autocomplete, we’ll capture the GUID silently.
Now save the section and test it.
3. Testing the Auto-Complete Search
Open the User Portal and create a new case.
Start typing in the Customer field:
Type C → Suggestions appear
If no exact match exists, it shows similar names
Example: Typing “Cri” may show Cristian
This works perfectly for large datasets. Avoid dropdowns when you have hundreds of rows—autocomplete is the correct approach.
4. What’s Next? Visibility Conditions
Now that customer selection works, the next step (in a future tutorial) is adding conditional fields.
For example:
Show address fields only after a customer has been selected
Reveal a section only when the customer is new
We will configure visibility based on the selected customer’s ID or property values.
✨ Final Thoughts
In this tutorial, you learned how to:
✔ Import CSV data into a Pega Data Type ✔ Map and validate records during import ✔ Build an auto-complete search field using a Data Page List ✔ Capture the selected record’s unique ID ✔ Test your search functionality in the User Portal
These skills are essential for building real-world Pega applications using best practices.
Welcome back! In today’s tutorial, we will continue building our application. Specifically, we will:
Create an optional action to allow users to add a new customer
Configure the UI to capture customer information
Save the data into a data type and create a new record in the database
Fix common mistakes and review troubleshooting tips
Let’s get started.
1. Creating the Optional Action
So far, we have only built our Customer Search feature. Now we want users to have the option to create a new customer if the search doesn’t return a result.
To create an optional action:
Go to the Case Life Cycle panel on the left side.
On the right panel, find Optional Actions.
You can add:
A single-step form
A multi-step form
A process
For this tutorial, I created a process that includes a form for entering new customer details.
2. Creating the Flow Action and UI Section
Inside the optional action process, we created a flow action, and inside that flow action we added a section that contains the customer fields.
I kept the form simple with just a few fields so it’s not too cluttered. The values entered here will be used to create a new customer record in the database.
3. Preparing the Data Structure
To save data into a data type, Pega requires a single page property mapped to the class of your data type.
You can create this by navigating to:
App Explorer → Data Model → Property → New Property
Set the property type to Page
In Page Definition, enter the class of your customer data type
We will use this single page later in our save operation.
4. Using the “Save Data Page” Automation Shape
Initially, I mistakenly selected Load Data Page, but for saving we need the Save Data Page automation shape.
To configure it:
In the flow, remove the incorrect shape (if needed).
Add Save Data Page from the Automation palette.
Open the shape and choose the page property associated with your data type.
Select the identifier that will be used as the record key (e.g., CustomerID).
5. Creating the Data Transform (Mapping Values)
We now need a Data Transform to map values from the UI into the data page before saving them.
Steps:
Create a new Data Transform (e.g., CreateNewCustomer).
Generate a unique key using: @pxGenerateUniqueID() This will populate the record ID automatically.
Map all the form fields (source) to the customer data type properties (target).
Save the rule.
6. Testing the Flow (First Attempt)
At this point, I tested the functionality, but noticed an issue: The optional action wasn’t appearing in the case.
This happened because I was using the UI Kit theme, which lacks certain newer UI features.
7. Switching the Application Theme to Cosmos
To fix that:
Open the Application rule.
Change the UI theme to Theme-Cosmos (latest version).
Save the rule.
Open the Skin rule and change inheritance to a Cosmos skin.
Save and log back in.
Now the optional actions show correctly in the portal.
8. Fixing the Optional Action Label
Inside the flow action rule, update the Label to something meaningful like Create New Customer.
Refresh the portal, and the new label appears.
9. Saving the New Customer Record
Enter the customer details in the optional action form and click Submit.
Initially, I made another mistake—trying to create a separate property and link it manually. The correct approach is:
Use a savable data page
Set the Data Source to a Data Transform
Map properties from pyWorkPage to the data type
Generate the ID in the Data Transform
10. Correct Savable Data Page Setup
A proper configuration includes:
Data Page
Structure: Page
Scope: Thread
Data Source: Data Transform
Parameters: Include the record ID (e.g., CustomerID)
Data Transform
Add pyWorkPage under Pages and Classes
Map:
Form fields → Data type properties
Auto-generated ID → Identifier property
Once saved, this Data Page can be invoked:
From a flow action (post-processing) or
From a Save Data Page automation shape
Both work.
11. Testing the Final Working Configuration
Create a new case.
Open Create New Customer.
Enter the information.
Submit the form.
Open your data type, click Records, and you will see the new row created successfully.
This confirms that:
The Data Transform ran correctly
The savable data page executed
The database updated without errors
12. Troubleshooting Tips
Use the Clipboard to inspect the data page and verify that:
Parameters were passed
No errors occurred
The record key was generated
Check Pages & Classes if a Data Transform can’t resolve properties
Ensure the savable data page’s Data Source is set to Data Transform, not connector
If optional actions don’t appear, verify the UI theme is Cosmos
Final Thoughts
This tutorial covered:
Creating optional actions
Designing a form to collect customer information
Configuring a savable data page
Mapping data using a data transform
Saving a new record into a data type
Troubleshooting common issues
I hope this helps you better understand how to manage and save data into Pega data types. Check out my blog (linked in the video description) for a more detailed, step-by-step guide.
Thanks for watching, and see you in the next tutorial!
Pega is a low-code platform designed to help organizations build applications that automate business processes, manage workflows, and make intelligent decisions using AI and rules. It’s widely used across industries like banking, insurance, healthcare, and government to increase efficiency and improve customer experiences.
Creating a New Application in Pega
To create a new application using Dev Studio, follow these steps:
1. Start the Application Wizard
Log in to your Pega environment.
Click Application → New Application.
You’ll be presented with two options:
Build from scratch
Select an existing application type from Pega’s out-of-the-box (OOTB) offerings
If you click Search all types, you’ll see a list of available applications. Since the Personal Edition includes fewer preloaded apps, we will proceed with Build from scratch.
2. Choose the Application UI Architecture
Pega provides three UI frameworks you can build your app with:
Traditional UI
Cosmos (modern, flexible, dynamic)
Constellation (the latest React-based, component-driven UI model)
For this example, we’ll select Traditional UI, then click Next.
3. Name and Create the Application
Enter a name for your application and proceed to create it.
You will then be prompted to define:
User types
Roles
For now, we will skip this step and click Done.
4. Why You Don’t See the App Immediately
After creating the application, you might notice that it doesn’t appear in your Application menu.
This is expected.
When Pega creates a new application, it also generates required system assets—one of those is an Access Group. Access Groups determine:
Which applications a user can access
What permissions and roles they have
Since your operator ID does not yet include the access group for the new application, you cannot access it.
5. Assign the Access Group to Your User
To add access to the new application:
Click your operator name in the lower-left corner.
Select Operator → Application Access.
Search for the Access Group created for your new app.
Add it to your user profile.
Log out and log back in.
After logging in again, your new application will now appear in the Application menu.
Your application is ready! From here, you can start configuring case types, data objects, UI components, and more. Let me know if you want a follow-up tutorial on building your first case type or setting up data structures.
In this tutorial, we’ll walk through how to create an external data source in Pega, configure it using an external REST API, and finally use it to populate a dropdown in a case.
1. Creating the Data Object
To begin, go to:
Data → New
This opens the wizard for creating a new data object.
Enter a name for your Data Object, then click Next.
In the System of Record dropdown, select Create new, and enter a name for the new system of record.
For this example, we will integrate with an external API that returns a list of countries.
2. Defining the External Data Source
Since we are retrieving information, we’ll use a GET method.
Enter the endpoint URL for the external API.
In this example, the service does not require headers or authentication, so we can simply click Initialize call to generate the structure.
3. Selecting the Fields to Source
The API response includes multiple details—country name, currency, languages, and more. You do not need to map all values. Instead, select only the properties you need.
Click Add new and choose the specific fields that should be included in your data object.
Environment Settings
This section displays the Integration System Settings created automatically. These help manage different endpoints across development, staging, and production environments.
4. Reviewing the Generated Data Type
Open the data type you just created. You will notice:
The System of Record is set to External
The data source is the Get Countries API
The wizard also automatically generates a Data Page in Page List mode. This Data Page is ready to be used as the source for:
Dropdowns
Autocomplete fields
Any UI component requiring country data
5. Reviewing the Generated Data Page
The Data Page is already configured with:
The Connector
The Response Data Transform
Since the API does not require parameters, no Request Data Transform is needed.
Click Run to test the Data Page. This confirms:
The API connection is successful
The response mapping works correctly
All returned data is visible under pxResults
You should now see a list of all countries retrieved from the API.
6. Using the Data Page in a Dropdown
Next, let’s use the Data Page as the source for a dropdown field.
In your case or UI section:
Select Field type: Data Page
Enter the Data Page name created by the wizard
Set the parameter value to countries (or the name used in your Data Page)
For the Property value, select Alpha Code
For the Display text, select Name
Click Save, and then run a case to verify that the dropdown loads correctly.
Open the dropdown and choose any country. Check the Clipboard to confirm the selected country is saved properly.
This completes the process of creating and using an external data source in Pega—from configuring the API to integrating it into your UI. If you have any questions or run into issues, feel free to ask!
