What are the use cases for Savable Data Pages over 'normal' Data Pages?

The use case for a Savable Data Page is where your Pega application has a need to modify - as well as read - concrete data from a System of Record that may or may not be Pega.

A 'normal' Data Page encapsulates / abstracts / hides the implementation detail of how an instance(s) of application data is retrieved from its System(s) of Record. Your Pega application's "business component" (a case type, a service) asks the Data Page to provide the data only when the application needs it; the business component does not concern itself with how the data is gathered.

So too a Savable Data Page encapsulates / abstracts / hides the implementation detail of how an instance(s) of application data is recorded in its System(s) of Record. The business component takes responsibility for capturing and validating changes to the already-retrieved instance(s), instructs the Savable Data Page when the right time to record it is, but again the business component does not concern itself with how the update is applied.

This allows "business components" in Pega to be built on the promise that Data Pages can both obtain and "post back" the data the business components depend upon, in isolation of the specifics of how the retrieval and modifications are performed on that data. These business components can remain explicit on when the data is needed and also when it is in a state that is ready to be recorded.

Discussion on this topic was sought from the LSA Data Excellence (Pega 8.4) webinar conducted in July 2020. The webinar and its full set of discussions that arose from it are available at LSA Data Excellence: Webinar, Questions & Answers.