Hi @TanyaS58

Lets take an example of insurance domain based application:

In an insurance application built on Pega, a user data page may store information specific to an insured individual's policy details and coverage preferences. When a user logs in, their policy information, such as coverage limits, deductible amounts, and selected add-ons, is loaded into their user data page. Throughout their session, the application accesses this data page to provide personalized insurance recommendations, renewal reminders, and claims assistance tailored to the user's policy.

Now, let's consider the use of an editable data page in the insurance application. Suppose the application allows users to update their contact information, including their mailing address and phone number. In this scenario, an editable data page is utilized to hold the user's contact details. Users can access this data page to view their current contact information and make edits as needed. For instance, if a policyholder moves to a new address or changes their phone number, they can update the information directly within the application. Once the changes are saved, the editable data page reflects the updated contact details, ensuring that the insurance company has accurate and up-to-date information for communication purposes.

Refresh Strategy: Editable data pages typically do not have a built-in refresh strategy, as their purpose is to hold data that users can directly modify within the application.

Once users make changes to the data within an editable data page and save those changes, the data is updated in the system and reflected immediately. There's no need for a refresh strategy in this context, as the data is dynamically updated as users interact with it.

Node Level: For data synchronization purpose, editable data page does not have the Node level scope.

I hope this clarifies things for you.

Thanks,

Ravoof.

Hi @TanyaS58

Lets take an example of insurance domain based application:

In an insurance application built on Pega, a user data page may store information specific to an insured individual's policy details and coverage preferences. When a user logs in, their policy information, such as coverage limits, deductible amounts, and selected add-ons, is loaded into their user data page. Throughout their session, the application accesses this data page to provide personalized insurance recommendations, renewal reminders, and claims assistance tailored to the user's policy.

Now, let's consider the use of an editable data page in the insurance application. Suppose the application allows users to update their contact information, including their mailing address and phone number. In this scenario, an editable data page is utilized to hold the user's contact details. Users can access this data page to view their current contact information and make edits as needed. For instance, if a policyholder moves to a new address or changes their phone number, they can update the information directly within the application. Once the changes are saved, the editable data page reflects the updated contact details, ensuring that the insurance company has accurate and up-to-date information for communication purposes.

Refresh Strategy: Editable data pages typically do not have a built-in refresh strategy, as their purpose is to hold data that users can directly modify within the application.

Once users make changes to the data within an editable data page and save those changes, the data is updated in the system and reflected immediately. There's no need for a refresh strategy in this context, as the data is dynamically updated as users interact with it.

Node Level: For data synchronization purpose, editable data page does not have the Node level scope.

I hope this clarifies things for you.

Thanks,

Ravoof.