Pega Savable Data Pages: From Data Retrieval to Data Persistence

User Experience Knowledge Share
1

:large_blue_diamond: Pega Savable Data Page — Read, Update & Save in One Place

A Data Page is not always just about reading data.

When an application needs to retrieve data, allow changes, and persist those changes back to the source, a Savable Data Page can provide a clean and reusable approach.

:fire: WHY NOT JUST OBJ-SAVE?

A common question is:

“If Obj-Save can save data, why do we need a Savable Data Page?”

The key difference is where the data-access and save behavior is managed.

:blue_circle: Obj-Save → Performs the save operation on a Pega object.

:green_circle: Savable Data Page → Provides a reusable data-access layer where the save behavior is configured for the Data Page.

So the real advantage is not simply replacing one save method with another.

It is about centralizing and reusing data-access logic.

:red_circle: TRADITIONAL FLOW

:page_facing_up: Fetch Data

:right_arrow: Map to Page

:right_arrow: Update Data

:right_arrow: Obj-Save

:right_arrow: Commit

This approach can introduce:

:cross_mark: More processing steps
:cross_mark: Additional mapping
:cross_mark: Duplicate save-related logic
:cross_mark: Logic spread across different places
:cross_mark: Higher maintenance effort

:green_circle: SAVABLE DATA PAGE FLOW

:page_facing_up: Fetch Data

:right_arrow: Update Data

:right_arrow: Save()

With the save behavior configured on the Data Page, the consuming application can work with the Data Page without repeatedly implementing the underlying save logic.

:white_check_mark: Reusable
:white_check_mark: Centralized
:white_check_mark: Less duplicated code
:white_check_mark: Easier maintenance
:white_check_mark: Cleaner separation of concerns

:light_bulb: REAL-TIME EXAMPLE

:bank: Customer updates their Mobile Number

Traditional Approach

Data Page → Map → Update → Obj-Save

The application handles the mapping and save-related processing.

Savable Data Page Approach

Fetch → Update → Save

The application works with the Data Page, while the configured save behavior determines how the updated data is persisted.

The idea:

One reusable Data Page.
One place to manage the save behavior.

:star: WHY THIS CAN BE VALUABLE IN ENTERPRISE APPLICATIONS

:blue_heart: Reusable Design
The same data-access component can be reused across multiple parts of the application.

:green_heart: Cleaner Architecture
Business logic does not need to be tightly coupled with data persistence logic.

:orange_heart: Reduced Duplicate Logic
Save-related processing can be centralized instead of being repeated.

:purple_heart: Easier Backend Changes
Changes to the underlying data-access implementation can be managed within the Data Page design.

:heart: Better Maintainability
A consistent approach makes the application easier to maintain and evolve.

:bullseye: REMEMBER THIS

:blue_circle: Obj-Save
→ An operation used to save a Pega object.

:green_circle: Savable Data Page
→ A reusable data-access abstraction with configured save behavior.

:rocket: The goal is not “replace Obj-Save everywhere.”

The goal is:

Encapsulate → Reuse → Centralize → Maintain

That is where a Savable Data Page can add real value.

:speech_balloon: What do you think?

Have you used Savable Data Pages in your Pega applications?

I would love to hear about your real-time use cases or different approaches you’ve followed.

Enjoyed this article?

See suggested articles from our Constellation 101 series and view all our Knowledge Shares from our User Experience Expert Circle.

2 Likes
Constellation 101
2

Savable data pages are a great addition in Pega. I treat them as one stop shop for all your CRUD operations on a data object that are either locally sourced or with external source.
However, one trade-off is for savable data pages that are of type list.. you still need an activity and obj-xxx to get the job done.

5

Absolutely, I agree with that. :+1: Savable Data Pages are a great way to provide a reusable layer for CRUD operations across locally sourced or external data.

One important distinction I would add is that the Savable Data Page itself doesn’t perform the actual persistence. It invokes the configured Save Plan, and the Save Plan determines how the data is persisted.

For example, depending on the requirement, the Save Plan can invoke an Activity that performs Obj-Save and Commit, or it can invoke a Connect-REST service for an external system.

So I see the Savable Data Page more as the orchestration/data-access layer, while the Save Plan routes the save request to the appropriate persistence mechanism.

And yes, the Page List/typelist scenario you mentioned is an important trade-off to consider. Thanks for bringing that up! :+1:

6

yes, one more point that I forgot to highlight in my previous response, we always don’t need an activity to trigger the save plan of the data page apart from Save-data page smart shape and flow action.
We can persist the transaction inside a data transform by calling below,
for create operation:
pxExecuteAnActivity(DPageName, “pxCreateRecord”)
for update operation:
pxExecuteAnActivity(DPageName, “pxUpdateRecord”)

7

@Naveen_Ganguri thanks for sharing - I have added it to our constellation 101 series!

Enjoyed this article?

See suggested articles from our Constellation 101 series and view all our Knowledge Shares from our User Experience Expert Circle.

1 Like