Apologies for my ignorance, but that sounds like an extreme corner case. Do you have any "normal" uses of such a feature that would improve efficiency over the tried-and-tested use of an activity? Activities are generally the most useful way of persisting data, mainly due to the level of control it gives us (despite Pega's constant exhortations not to use them). Why should we change?

I am not suggesting we shouldn't use this new feature, I just can't see any reason why I should give up solid, reliable logic for something new just because it's "shiny".

I've recently worked with a lot of ReST service calls and found that wrapping the connectors in data pages is a useful pattern with several benefits, whether querying or updating the external SoR.

• It's easy to implement a data page that uses a connector as a source. The initial data page is created by the integration wizard.
• You can re-wrap the connector in different data pages with unique names to implement specific query or update functions and make the purpose clear to other developers. For example, these data pages might all use the same connector with different input params and different request data transforms:
  • D_GetAccountInfo
  • D_SetAccountStatus
  • D_DeleteAccount
• The same response data transform can be used for all data pages that use the same connector source.
• Error handling can be encapsulated in the response data transforms and reused across multiple service calls. 

Yes, you can do all this with activities but I've found that with this pattern I rarely need to write an activity. Data transforms are sufficient and the code is easier to maintain.

You are free to choose "Activity" as a "Save type" when configuring a Savable Data Page.

Other options are Robotic Automation, and Robotic Desktop Automation.

For Structure=Page Data Pages a fourth option exists, namely, "Database save".

It makes sense that if you can configure a Data Page to do a Lookup you should also be able to define a Structure=Page Savable Data Page to update that row in the database, or if the row does not currently exist, insert it.  No Activity required.

For Structure=List Savable Data Pages, when not using Robotics, an Activity must be used to save the data.

Savable Data pages is a best option to seperate persistance logic from business logic of activities, where there is persistance logic only required without processing data like post flowaction or within the flow directly Savable Data pages can be referred instead of calling activities with "Obj-Save" methods.

One more point is you need to deal -when you have WSDL with Complex Type Data Elements in Robotic Automation you have to use Service Client , Service Client do not have easy way to form request  or even map the response , all you need to do in your string utils and other manipulation , no automatic way to form different parsing rules , forming request extra. So this situation we can utilize Data Pages , recent latest version of Robotic Studio SP- included Data Pages, it helps big time.

I found them to be a great addition when you're working with locally stored data not tied to a specific case.

Suppose you have a list a products and you need to update the price. Before you had to create an activity just to do an obj open, apply a data transform and perform an obj-save. Now you can use a savable data page which is much more intuitive.

As i see it activities should be your last resource for complex logic. Updating a value in a SOR should (and now is) accomplished without activity.

Now it would be great if we could insert records too and not only update them :)

You can insert records using a Savable Data Page.  

Start with an embedded page property NOT sourced to a Savable Data Page.

Next create a Data Transform that has the same applies-to class as the embedded page property .

Call the Data Transform from the case, for example as a Flow Action post transform.

If any embedded page property used as a unique key does not contain a value, the Data Transform should set one.  For example if the data instance uses pyGUID as a unique key, set it equal to @Utilities.pxGetNewGUID() or just check the "Automatically generate a unique ID for records of this type" box within the Class rule. 

Next update the Savable Data Page setting it equal to the embedded page property. The syntax for the Savable Data Page will require that you to supply the value for each unique key as a parameter. 

Afterward use a Save Data Page step to save the data. That step will ask you to supply the keys. 

If you trace the Savable Data Page you will see it complain about lookup failing. Nonetheless the Savable Data Page will contain the properties copied from the embedded page.