Scope of data pages

The scope of a data page defines the thread that can access the data page. You can select the scope on the Definition tab of the data page.

A data page scope can be node, thread, or requestor:

• Thread – The page is created in a single requestor thread and can be accessed as often as needed by processing in that thread.
• Requestor – The requestor can access the page(s) loaded across all threads.
  Note: For Customer Service chat interactions, associate requestors have their own copy of requestor-level pages. For editable requestor-level pages, changes made in one chat interaction are not seen by other phone and chat interactions.
• Node – Any requestor executing on the current node can access the pages.

Types of data pages

There are three types of data pages:

• Read-only – This is a read-only page available to only one thread, a requestor, or multiple requestors (on one node) in your application. Read-only data pages can be modified only during page load and post-activity processing. These data pages are displayed in the data page list on the clipboard.
• Editable – This page contains initial contents that can be accessed in read-write mode. Editable data pages do not have a refresh strategy or save plan and cannot be node-level in scope. These data pages are displayed in the user page list on the clipboard.
• Savable – This page provides a save plan through a database source or an activity so that users can update data and write to a system of record. Only savable data pages can be referenced in save data page locations, which are areas in the application where you can list data pages to save. For example, you can list the pages to save in flow actions during postprocessing, the Save Data Page shape to use in Case Designer or the Flow form, and the Save-DataPage method to use in activities.

Refresh strategy for data pages

The refresh strategy for a data page determines the time period for which the data page is valid. You can define the refresh strategy on the Load Management tab of the data page.

You can define the following refresh strategies for a data page:

• Reload once per interaction – The system refreshes the data page exactly once per user interaction. This option is available only for data pages with a scope of thread or requestor.
• Do not reload when – You can define a when rule for this refresh strategy. If the when rule evaluates to false, the data page contents are refreshed, but never more than once per user interaction.
• Reload if older than – You can define the amount of time after which the data page is considered expired.
• Restricted feature set for high throughput – When high-speed read-only data pages are impacting system performance, you can use a restricted feature set to improve performance.

For more information, see Configuring the refresh strategy for data pages.

Access restriction while retrieving data from data pages

You can assign access control policies to classes which restrict retrieving data from those classes. If a node-scope data page is defined on such a class, a severe guardrail warning is shown. Also, if a node-scope data page is populated and the data page object class has access control policies assigned to it, a severe security alert is shown.

Data pages (known previous to Pega 7 as "declare pages" and "declarative pages") store data that the system needs to populate work item properties for calculations or for other processes. When the system references a data page, the data page either creates an instance of itself on the clipboard and loads the required data in it for the system to use, or responds to the reference with an existing instance of itself.

Both UI and non-UI elements (like data transforms) can reference data pages, without the use of an activity.