Enable and configure auto-save in Constellation

User Experience Knowledge Share
, ,
1

Auto-save is a feature that has been requested in Constellation by many clients. Before Infinity '26, to achieve auto-save functionality you had to build a custom DX component.

What is new in '26

Infinity '26 delivers OOTB support for auto-saving assignments. With a simple toggle on the case type settings, you can enable auto-saving all assignments in the case.

image
image1719Ă—487 58.9 KB

Key details:

  • Setting applies to all assignments in the case type
  • Save happens when user is not active/typing
  • The default save interval is 5 seconds

How to configure the save interval

“But wait - a 5 second interval does not suit my business”.

Luckily, the save interval is configurable. As of writing this article, this setting is not exposed alongside the checkbox to enable autosave. Instead, it is configured in the feature map data transform “pyC11nFeatureMap”. Update the value of “.pyAutoSaveDurationInMS” to change the save frequency interval.

image
image2479Ă—842 213 KB

Important: If you decide to change the frequency by forking/specializing the “pyC11nFeatureMap” data transform, remember to include it in your upgrade assessment when a new platform version becomes available (since your copy will not automatically include any updates made to the rule by Pega).

To consider

Before heading straight for the auto-save setting, it is important to stop for a second and think about the reason you want to enable it. For example: If your users are losing work, is auto-save the real solution or would it serve as a band-aid fix to mitigate the issue instead of solving the real problem? Modifying authentication timeouts, investigating browser crashes, etc. would be the better things to start with before considering auto-save.

Implementation video

image

:play_button: Watch now →

Documentation

Pega documentation for auto-save: Pegasystems Documentation

Enjoyed this article?

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

12 Likes
2

Thanks for sharing Andreas, this looks to be feature that many organizations will benefit from!
A couple of follow-up questions that you might be able to answer based on your research:

  • Did you by chance check as well if there is any performance impact on larger cases with many fields that need to be auto-saved?
  • And am I correct in understanding that the auto-save (just like the normal save button) commits the data to the DB, which means that for reporting purposes, we need to carefully think about statuses of the case?
    E.g. in case status A, these fields might have content saved, but they are in draft until the case progresses to status B.
3

@Tim_Straatsma Great questions.

  • Performance: I did not test it in practice yet (very new feature :wink:), but as a general advice, the same guidelines from before still apply. Try to split forms into multiple if they have a huge number of fields. The auto-save functionality uses the exact same save API as the save for later button, so whatever behavior you had before, you will have with auto-save. Something extra worth considering is that auto-save can become very chatty if you keep a low save duration. A save “roundtrip” interaction (shown as loading spinner in the article’s video) is around ~500 ms even for a small form. Pair this loading event with a very chatty duration and the experience for your users can start to feel like things are always loading.
  • DB commit: As mentioned above, it uses the same save API as before. So whatever the platform did and does, auto-save also does. This means that currently, a DB commit is done, yes.
3 Likes
4

Thanks for sharing Andreas, With Pega now providing this capability out of the box, it will be interesting to see how the Auto Save feature handles case types configured with optimistic locking.

5

@Anurag Welcome back to the forum! Agree, it is an interesting point. It works the same as it did before, for example if both users try to hit “save for later”. If one requestor makes an update and you have autosave enabled, the other requestor will get error as soon as they trigger the autosave duration point or leave the field (“on blur”). So, the “whoever did the update first” still applies, even if auto-save was the trigger rather than a button click.

1 Like