I'm saving multiple Savable Data Pages on completion of the one Flow Action. What are the considerations for transaction management, data integrity, error handling, commit and rollback?

The considerations aren't any different compared with if you had implemented this in Post Processing Activities prior to the availability of Savable Data Pages.

Any Savable Data Page listed on the Flow Action that has messages on it after an attempted save will:

1. Add a distinct message to the work page indicating a Savable Data Page save failed; 
2. Attempt the Save plans for any subsequent Savable Data Pages configured on the Flow Action;
3. Continue to the Flow Action's Post Processing Data Transform or Activity. 

By adding a message to the work page when one or more of the Savable Data Pages fail their save plan, the Post Processing rules which finish with messages on the work page cause Pega to cancel its deferred saves and revert to the last idle point (just like it always has). Typically, this is the current assignment, redisplaying the UI with the currently entered data and error messages.

The key design considerations are:

1. If you are using an Activity to orchestrate your Savable Data Page's save plan, set a message on the Data Page if the save should be deemed by Pega to have failed. This will cause Pega to flag a message on the work item that will prevent the Flow from proceeding;
2. All Savable Data Pages listed on the Flow Action are attempted, regardless of whether earlier ones listed succeed or fail.
3. The Post Processing rules of the Flow Action are still performed even if a Savable Data Page failed its save operation. Any compensating actions to be performed on Savable Data Pages that were deemed successful should be orchestrated from the Post Processing rules of the Flow Action. Each Savable Data Page listed in the Flow Action can (either explicitly or using the auto-populate property it is bound to)  -- in Post Processing rules -- have the When rule 'hasMessages' performed on it to determine which Savable Data Pages are reporting failures.
4. If all Savable Data Pages succeed, but other Post Processing detects a failure condition, the compensating actions for all Savable Data Pages to external systems will need to be invoked as Pega is going to roll back to the assignment UI.

The above provides an approach to retain data integrity across systems for the 'transaction' (the Flow Action), either:

• Everything was successful; the Flow Action completes; the Flow progresses; database changes are committed in Pega; changes outside of Pega are done by the time the next assignment is created; OR
• Something failed; no changes in Pega are persisted; changes made outside of Pega are undone when a Post Processing rule invokes the relevant compensating actions.

Data Pages whose Save Plans successfully executed a "Database save" issue a deferred save. If come the end of Post Processing there is an error that triggers a rollback, these earlier deferred saves are rolled back as if they were not done ... just the same as Obj-Save's done in a Post Processing Activity that later detects a failure condition and adds a message to the workpage.

If WriteNow was requested on the earlier successfully executed Savable Data Pages, these are committed as part of the Save action and won't be rolled back to the state they were in before the assignment ... just the same as Obj-Save using WriteNow done in a Post Processing Activity. This data integrity risk is why there is a guardrail warning on using WriteNow.

Don't ever use Commit in your Save Plan activity as this will commit deferred saves that are unrelated to what you intend to save via your Savable Data Page. 

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.