Trouble using data page as a source for an insight

I am using Pega Infinity 24.2.4.

I’m having trouble with using a Data Page with a report definition as a source for an insight to make a chart.

If I check “Query Options - Allow querying any column (Pega connection only)” then the data page does not show up in my explore data data page list.

If I leave it unchecked, then I can find the data page, but when I try to add a measure to an insight chart, it does not aggregate that measure (so for instance Case ID just stays as Case ID instead of Case ID (Count))

The documentation says that “Allow querying any column” is required for data pages to be used in insights, but it does not show up in the list when I do so.

I have cleared my cache, tried private browser sessions / other browsers, and have consistently got the data page to reappear when unchecking the query options box. Can anyone suggest troubleshooting steps here?

can you try your Data Page is explicitly configured for reporting by setting the Structure to List and the Edit Mode to Read-Only. Once these are set, you must check the Allow querying any column checkbox to satisfy the Insight requirements, but you must also ensure the Data Page is defined in a UI-accessible Class that matches your Explore Data context. If the Data Page still does not appear in the list after checking the box, navigate to the Data Model tab of your Case Type or Data Object and manually add the Data Page as a source to refresh the platform’s metadata index. This action forces the Insight engine to recognize the “Querying any column” capability, allowing the Data Page to appear in the Explore Data list and enabling the aggregation functions like Count or Sum for your chart measures.

If I understand the requirement correctly, you are trying to use a Data Page (sourced from a Report Definition) in Insights and facing issues with aggregation based on the Allow query setting.

Just to clarify, is your goal to:

  • Use the Data Page purely as a reporting source for Insights? or

  • Apply any additional transformation/filtering on top of the Report Definition?

I tried replicating a similar scenario and observed that when Allow query is unchecked, the Data Page may appear but does not support proper aggregation (like Count), as it behaves more like a UI data source. Handling measures in a response Data Transform might work for display, but it won’t behave correctly in Insights and is not recommended.

When Allow query is enabled, the Data Page is treated as a query able source, and aggregation works based on the underlying Report Definition / Data Object.

In most reporting scenarios, using the Report Definition directly tends to be more reliable unless there’s a specific need for additional processing in the Data Page.

Hi Sairohith, thank you for your response.
I have confirmed its a List, Read Only data page in a UI accessible class matching the explore data context. As long as I leave “Allow Querying Any Column” unchecked it appears in the data page list. When I check the box, the data page vanishes from the list.

When you say to add the data page as a source to refresh the platform’s metadata index, are you saying to add the data page as the source for a query field?

Hi Shirisha, thank you for your response.

The goal is for the data page to add a data transform to the underlying data (namely business days the case has been open - Not standard calendar days).

When you say it’s not reliable when using data transform for insights, is there another method for calculating fields before insights charting? I have tried declare expressions which did not work. My only other idea is to create a job scheduler to regularly calculate business days open and add it to the case data, but that could cause issues with locked cases.

Hi Michael,
I recently explored a few approaches for a similar scenario we encountered, sharing them below:

Scenario 1 - Calendar Days in a Chart

If calendar days are acceptable, Pega v25.1 supports built-in Calculations inside Insights. You can add a Difference in days function directly in the Insight:

Function: Difference in days
Earlier datetime value: Create datetime (pxCreateDateTime - available in the dropdown)
Later datetime value: Now

Set this as a Measure and Case ID as the Dimension. This gives one bar per case with no additional rules needed.

Limitation: this counts all days including weekends. For true business days, see below.

Scenario 2 - True Business Days (Worked well with table)

For business days excluding weekends, the value needs to be calculated using Pega’s Business Calendar function and persisted to the database. Insights queries the database directly, so runtime-only values will not show in charts.

Approach A - Declare Expression

  1. Create a BusinessDays (Integer) property on your case class, optimized for reporting
  2. Create a Declare Expression with Recalculate: Always and the following expression:

@BusinessCalendar.differenceBetweenDays( .pxCreateDateTime, @CurrentDateTime(),true, “default”)

The third parameter true is what excludes weekends via the Business Calendar.

  1. Also set the same value in pyDefault Data Transform so it is persisted on case creation
  2. Once cases are saved, drag BusinessDays into Insights as a field for table view or as a Measure for chart view

This avoids the job scheduler concern you mentioned entirely. The Declare Expression recalculates when the case is accessed rather than through a batch run, so there are no locked case conflicts.

Approach B - Response Data Transform of a Data Page

If your case is always loaded via a Data Page, you can set the same expression in the Response Data Transform. The trade-off is that the value only persists if the case is explicitly saved afterward, and Data Page caching can affect reliability.

One important prerequisite: If cases are not persisted to the database, Insights will return no results regardless of how the properties and calculations are configured.

Hope this helps. Happy to clarify any of the steps.

Hi Shirisha,

Unfortunately the requirement is business days, so I can’t use calendar days.

Approach A is what I tried originally, the problem is that this is to be used in an insight to check on agents’ progress. If an agent doesn’t access those cases, then the “business days open” will stay at whatever the last accessed value was (so if they create a case and then orphan it, even 10 days later it will say 0 business days open).

The response data transform for approach B does work for the data page, but only for a table. The charting apparently requires the page to be queryable (to do aggregate functions like count) and because the data transform is not a part of the object/case data, it only shows up as what is on the case. So if my DT sets a value to 10 for the data page, but in the case object the value is 0 then in table view I will see 10, and in chart view I will see 0.

I opened an SR with Pega Support on this, and learned that only one queryable data page is allowed per case type, and that is the “XYZ_List” for case types. Even modifying that queryable data page’s report / data transform are not getting me results.

correct, the queryable datapage for the data object (in default data sources under settings) is not really that important - its a starting point for Insights to create a virtual report definition on the data object (which will be constructed from the rules in the class, like relevant records, associations, optimized embedded properties etc.).

@Shirisha_Boinapalli 's solution "Scenario 1 - Calendar Days in a Chart" is the right track, in '25 you could specify your own calculations and even custom functions for those calculations to do business days BUT you said you’re on '24.

In '24 the only way to achieve this, for a Chart, would be to physically create this property in your data model and populate it (rather than trying to do it in a response data transform on data page).

Personally, I would look to implement this as an Insight Table or List View, so the users can get to the data, until you can get to '25 and put it in a chart type to enhance the UX.

@MICHAELB17425237 Are you in the User Experience Expert Circle? I would like to move this under that area, so it can be found with other Constellation questions. However, if you are not a member you won’t be able to respond (until you join), so don’t want to just move on you.

Please let me know if you join and i’ll move.

image