Chapter 1.

Savable Data page

Have you heard of the amazing capabilities of the savable data page in Pega? I'm absolutely
fascinated by it! This data page can not only read a record but also be used as an editable page and
then can be used to write the record back. And guess what? Recently, I discovered that it can even
be used to delete the record. Pega has introduced a new save option called "Database delete" in
version 8.8, like the save type "Database save." It is incredible, isn't it? And not only that, the savable
data page supports both page and page list structure. I am so eager and curious to learn more about
this feature, and I'm sure you will be too!

CURD operations using savable data page

Let's start with CURD operations using savable data pages. CRUD stands for Create, Read, Update,
and Delete. These are the four basic operations that can be performed on data. Now, let’s see how
to configure and enable the Create operation using a savable data page.

To illustrate, let's consider an example where you need to write data to a Pega data record. In order
to enable the Create operation, you need to first make some changes in savable data page with the
appropriate data sources and parameters. Let’s have a look at what is the default configuration set
on savable data page by pega for a data type.

When you create a new data type in Pega and enable it to store local records, the platform
automatically creates three data pages by default. These data pages are a single page, a page list,
and a savable data page. The default configuration of this savable data page is set for update
operation only, with single page structure. This means that the data page can be used to update an
existing single record in the system of record. The key parameter is a mandatory field in the
configuration of the savable data page, as it is required to identify the record to be updated. The
data source of the savable data page is configured to do a lookup based on the key, to retrieve the
record from the system of record for updating. Additionally, the save type of the savable data page
is set to "Database save" by default.

1
linkedin.com/in/christin-varughese-b968152b/
Action Type CREATE
If you want to configure the savable data page to perform a create operation, you need to modify
the configuration accordingly. You need to specify the key parameter as optional. This allows Pega to
generate an autogenerated key for the new record being created. In cases where a key value is not
provided, Pega generates a unique key value for the record being saved.

To generate an autogenerated key for a record being saved using a savable data page, you need to
enable it in the class. You can do this by adding a key part to the class rule and setting the 'Use
autogenerated keys' option to 'Yes'. When this option is set to 'Yes', Pega will automatically generate
a unique key value for each new record created in that class. This key value will be used by the
savable data page when saving the record to the database.

2
linkedin.com/in/christin-varughese-b968152b/
However, if you do not want to use the autogenerated key, you can set the key value in the savable
data page manually. To do this, you need to add the Key Value field to the data page. You can then
specify a value for this field (you can also set it using another parameter, let’s say TempIdentifier)
and Pega will use this value as the key when saving the record.

Defining the TempIdentifier parameter have some other benefits too. When working with savable
data pages, there may be cases where you need to use the same data page for multiple records or
page lists. "TempIdentifier" parameter can be used to differentiate between the records. For
example, when adding a new Primary and Secondary address in the same section, you can use
"Primary" and "Secondary" as the TempIdentifier value. Similarly, when saving a page list, you can
use the TempIdentifier parameter to keep track of the index of each record.

Defining the TempIdentifier parameter as an optional parameter in your data page allows you to use
the same data page for multiple records or page lists, without needing to create a separate data
page for each record. You can determine whether TempIdentifier should be used to keep the new
key value or to differentiate the records.

It is worth noting that when using autogenerated keys, Pega generates the key value only after the
record has been saved to the database. This means that the generated key value is not available
until after the save operation has been completed. If you need to use the key value immediately
after saving the record, you should specify the key value manually.

So, how can you tell Pega what operation to perform on a savable data page? You can define a
parameter called "pyActionType" with a value of "CREATE", "UPDATE", "UPDATE_PUT",

3
linkedin.com/in/christin-varughese-b968152b/
"UPDATE_PATCH", or "DELETE", where the CREATE option is used when creating a new record. This
is aligned with the CRUD (Create, Read, Update, Delete) operations used with DXAPI and React
components.

To enable the creation operation using the savable data page, you first need to configure the data
source to be empty, as you are creating a new record rather than looking up an existing one. This
can be achieved by creating a separate data source for the create action, which calls an empty data
transform. Otherwise, the data source will look up a record using the provided key. To determine
which data source to use, you can add a when rule (IsActionTypeCreate) that checks whether the
action type is set to create. This when rule can be configured to take the input parameter
"pyActionType", which will be used to verify if the current action type is a "CREATE" operation. Make
sure you pass this param from the when rule reference in the data source. With these configurations
in place, you can now proceed to create our example by writing data to a Pega data record using the
savable data page.

4
linkedin.com/in/christin-varughese-b968152b/
So, how can you populate the savable data page?

Let's take an example. Suppose you want to add a new address to the data record. To do this, you
can create a required section with all the address fields in the corresponding data class. This section
can be referred to from anywhere, such as a wrapper section. To make sure that the new address is
added to the savable data page, you need to give the page context as the savable data page. This can
be done by specifying the data page as the source of the section. Once the section is saved, the new
address will be added to the savable data page and can be saved to the database using the save
option provided by Pega.

Saving data in a data page

Pega provides multiple options for saving data in a data page, depending on the use case and
requirements.

5
linkedin.com/in/christin-varughese-b968152b/
If you want to save data as part of a flow action and maintain transactionality with the work item,
you can use post-processing. This involves saving the data to a data page after the flow action has
completed, so that any errors or exceptions during the flow action can be handled before the data is
saved.

For saving data in a data page as part of a case life cycle, Pega provides the option of auto-populated
property, where data is copied from a data page to the case properties using a property-set method.
Another option is to use an automation shape "Save data page" in the process flow.

If you want to save data in a data page when running an activity, you can use the Save-DataPage
method, which allows you to save data to a data page using the activity.

Let's take a closer look at these different options.

Option1: Saving data in a data page as part of a flow action

Let's say we have a case wide local action where we want to add a new address to our data record.
To implement this, we can create a required section with all the address fields in the corresponding
data class. We can then create a flow action that calls the wrapper section which refer the address
section and passes the savable data page as the page context. We can then use the "Post-
processing" option provided by Pega, which allows us to save data in a data page after the flow
action is completed. By using this option, we can maintain transactionality with the work item, which
means if any error occurs during the process, the changes made to the data page will be rolled back.

Pega provides multiple savable data page options that can be managed by a "When" rule. For
example, there are two address fields - "Primary" and "Secondary" for an address. In the wrapper
section you can refer the address section twice - one for Primary and another for Secondary and give
the savable data page as the page context for each. But since both are having same data type, and so

6
linkedin.com/in/christin-varughese-b968152b/
uses same savable data page, how pega will identify these two records as separate. Here is where
we need to use the additional parameter set on the savable data page, which is TempIdentifier. You
can pass TempIdentifier as "Primary" for primary address and "Secondary" for secondary address
reference. So, in post processing you can add both savable data page with the when rule "Always".

When using multiple savable data pages in a flow action, Pega provides a mechanism for maintaining
transactionality. This means that if one savable data page fails to update, any changes made to the
other savable data pages will also be rolled back, ensuring that the data remains consistent.

For example, suppose if the update to the Secondary address fails for some reason (e.g. a required
field is missing), then the entire transaction will be rolled back, including any changes made to the
Primary address savable data page. This ensures that the data remains consistent and accurate.

7
linkedin.com/in/christin-varughese-b968152b/
Use associated property" option
If you have a requirement to keep data on the case workpage and also update it in the data table,
then you can use the "Use associated property" option. This option can be found in the flow action's
post-processing section under the "Save data page" option. By using an associated property, you can
link the data on the case workpage with the data in the savable data page, making it easier to
manage and update the data.

For this you can create a new auto-populated property in the work class, let's say "PrimaryAddress".
Define the page definition of this property to be the address data class and set the option "Copy
data from a data page", where the data page is the savable data page. Then use ".PrimaryAddress"
as page context for the address section. When the flow action is saved using the "Use associated
property" option in the "Save data page" configuration, the data entered in the section with the
PrimaryAddress page context will be saved to the savable data page as well as the PrimaryAddress
property in the work class. Any subsequent changes made to the PrimaryAddress property in the
work class will be automatically reflected in the savable data page, and vice versa. This maintains the
transactionality between the work item and the data being saved, as changes made to one are
immediately reflected in the other.

8
linkedin.com/in/christin-varughese-b968152b/
Option2: Saving data in a data page as part of a case life cycle
Suppose you have a scenario where you receive new addresses in an ingestion file and after
mapping them, you want to save them to a Pega data table. In this case, you can set up the savable
data page from the mapping process and then call the savable data page using the automation step
"Save data page". This allows you to easily save the mapped addresses to the Pega data table as part
of the case life cycle.

The advantage of using this option is that it provides a streamlined approach for saving data to the
data table without the need for custom coding or manual entry. This automation step also allows
you to specify the data page name as a parameter, making it easy to save data to a specific data
page as part of your case life cycle.

Additionally, you can also use the "Use associated property" option. This allows you to keep the
address in the case workpage and update it to the data table, providing even greater flexibility and
control over how your data is managed throughout the case life cycle.

Option3: Saving data in a data page when running an activity

Let's take the example of a landing page for a customer where you want to update their address. In
this scenario, you can use a savable data page as the page context for the UI, which will allow you to
capture the updated address details. To save the updated address details to the Pega data table, you
can configure a button on the landing page to call an activity that uses the Save-DataPage method.

9
linkedin.com/in/christin-varughese-b968152b/
This method allows you to save the data page either as part of the current transaction or as a
separate transaction.

Another example, let's say you have an ingestion process that imports customer data from an
external source, including their address details. You can map the imported data to the savable data
page and then use the Save-DataPage method in an activity to save the data to the Pega data table.

One advantage of using an activity to save data in a data page is that it gives you more control over
the transaction. You can choose whether to save the data in conjunction with the rest of the
transaction or independently as a separate transaction. This can be particularly useful if you need to
save data in a data page as part of a more complex business process.

However, it's important to note that using an activity to save data in a data page is only
recommended for advanced use cases. Whenever possible, you should use a flow action or Save
data smart shape instead of an activity to save data in a data page. Additionally, you should not
include commit steps in save plan activities, regardless of whether the activity is WriteNow or not,
because the transaction being committed might include deferred saves from outside of your activity.

Let's dive into the different data save options provided by Pega to update the System of Record
(SOR) in real-time with case data.

1. Database save – With this option, you can save data to the System of Record (SOR)
database. For example, if you have a case with customer information, you can use this
option to update the customer's address in the SOR database. This is a straightforward and
reliable option for persisting data.

2. Connector – This option allows you to use a connector to save and persist data. Connectors
are used to integrate with external systems such as a CRM, an ERP or a third-party system.
For instance, you might want to update customer information in Salesforce based on the
information provided in your case. With a connector, you can easily make the necessary
updates to the external system.

3. Activity – The activity option enables you to create custom logic to persist data to any
system using any supported integration connector, such as REST or SOAP. With activities,
you can define complex workflows that allow you to manipulate the data in any way you like
before saving it. For example, let's say you have a case where you need to retrieve data from

10
linkedin.com/in/christin-varughese-b968152b/
 multiple sources before updating the SOR. In that case, you can create an activity that
retrieves the data and performs any necessary transformations before persisting it to the
SOR.

4. Robotic automation, and Robotic desktop automation – If you use robotic automation or
robotic desktop automation, you can use these options to source your data page when you
want to write updated data back to an external system of record, or when you need to use
robotics to meet other business needs. For instance, if you have a case where you need to
update a customer's order information in an external system, you can use a robotic
automation to perform the necessary updates.

In summary, Pega provides various data save options to update the System of Record (SOR) in real-
time with case data. Depending on your business requirements, you can choose the most
appropriate option. Whether it's a simple database save, a connector-based approach, custom logic
using activities, or using robotic automation, Pega has got you covered.

Action Type UPDATE

When it comes to updating data in a savable data page, we can use the pyActionType parameter to
identify the operation as an update. Since we are updating a specific record, we also know the
pyGUID of the record we want to update. Optionally, we can use TempIdentifier if there are multiple
records to update in the same screen.

Let's consider an example where we need to display an address and provide an option to edit it.
Instead of using the D_Address datapage to display the address, we can use a savable data page,
let's say D_AddressSavable, which provides the provision to edit the record. This way, we can read
the record and make any necessary updates.

The data save options will take care of updating the changes back to the system of record. If we are
working with local records, we can use the save to database option to update the data table.

Overall, using the update operation with savable data pages can simplify the process of updating
records and ensure that the changes are persisted to the appropriate system of record.

11
linkedin.com/in/christin-varughese-b968152b/
Savable datapage with a page list structure
So, let’s see how to use savable datapage with a page list structure.

Let's say you have a requirement to display a list of addresses for a customer and allow the user to
edit those addresses. To achieve this, you can create a savable data page with a page list structure to
store the address records.

To populate this savable data page, you can use a report definition as the data source, which allows
you to fetch multiple records based on specific criteria. For example, you can create a report
definition to fetch all the addresses for a specific customer.

Once the savable data page is populated, you can use it as the data source for a UI that allows the
user to edit the records. This UI can be built using sections or grids that allow the user to add, delete
or modify address records.

When the user submits the changes, you need to save the updated records back to the system of
record (SOR). In the case of a remote data source (such as a database or an external system), you
can use the data save options to update the records in the SOR.

However, if you are using a local data source, you need to use an activity rule to save the records
back to the SOR. This activity should first copy the records to a temporary page and then iterate
through each record to call the save method and update it in the SOR. It is important to save the
records using a temporary page, rather than directly on the savable data page, to avoid any
unexpected behavior.

12
linkedin.com/in/christin-varughese-b968152b/
Action Type DELETE
Now, are you curious about how to delete data using Pega's Savable Data Page feature? Let's take a
closer look! When working with data in a system, there may be instances where you need to remove
a record entirely from your system of record. This is where the DELETE operation comes in handy. By
utilizing this feature, you can easily remove any unwanted records from your data page, and
subsequently from your system.

To initiate a DELETE operation, you first need to identify the pyGUID of the record you wish to
remove. This will be passed as a parameter when executing the operation. You will also need to set
the pyActionType parameter to "DELETE" in order to properly identify the operation. Once these
parameters are set, you can then use Data Save Options to delete the record from your system of
record using the "Database delete" option.

In addition to setting the parameters and Data Save Options, it is important to configure a data
transform that maps the parameter's pyGUID to the appropriate .pyGUID property. This ensures that
the delete operation is properly targeted to the correct record.

13
linkedin.com/in/christin-varughese-b968152b/
Overall, utilizing the DELETE operation in conjunction with Savable Data Pages allows for efficient
and effective removal of records from your system of record, keeping your data organized and up to
date.

To summarize, when working with savable data pages in Pega, we have three main operations to
consider: create, update, and delete. For create operations, the calling rules are responsible for
populating the data page, while for update and delete operations, we typically use a lookup to fetch
the record to be updated or deleted. When performing data saves, we need to choose the
appropriate option based on the operation being performed. For update and create operations, we
can use the Database save option to save data back to the system of record, while for delete
operations, the Delete from data base option should be used. By carefully considering the data save
options and using lookup and calling rules as appropriate, we can ensure that our savable data pages
are used effectively and efficiently in our Pega applications.

Wow, what an amazing journey we have just embarked on with Pega Savable Data Pages! I hope you
are feeling as excited as I am about the endless possibilities and capabilities of this powerful tool.
With the knowledge you have gained in this first chapter, you are well on your way to becoming a
Pega SSA superstar. Keep pushing forward and exploring all that Pega has to offer, and get ready for
even more exciting revelations in the next chapter!

14
linkedin.com/in/christin-varughese-b968152b/