We need to pass the file fields available on the OperatorID page to Insights. We have added these fields to the pyGetSystemPagesForInsightsExtension data transform and are able to configure them successfully. However, they are being passed to the query as literal strings. For example:pxCreateOperator = “OPERATORID.PYUSERIDENTIFIER” instead of the actual value. We are able to use pxRequestor references successfully, but we also need to pass several business-specific fields that are available only on the OperatorID page.
Could you please advise whether any additional configuration is required ?
Could you please confirm if you’re able to mark it as Relevant fields, then you should be able to show business specific fields during Insights configuration?
Seems like Insights is treating your added entry as a static name instead of evaluating it as a clipboard reference.
pxRequestor is a standard requestor page and is commonly available in runtime context, so it can be resolved directly in some reporting/Insight scenarios. However, OperatorID.pyUserIdentifier may need to be sourced through data page/ initialised clipboard paga that the runtime explicitly knows how to evaluate otherwise it can be treated as the string “OperatorID.pyUserIdentifier” rather than the page property value.
You can try fetching the operator details using ‘D_pxOperatorDetails’ and use that in the report/Insight source rather than the direct OperatorID reference. If runtime filtering is required, using a parameterless data page wrapper is usually more reliable than referencing OperatorID directly in the Insight configuration
We need run time filtering because bunch of Insights are built on the same class. Could you please elaborate on the wrapper data page. We cant use separate data page as there are chart type Insights.
@AbhilashK2788 The wrapper data page pattern is the cleanest option for runtime filtering across many Insights built on the same class. You can create a wrapper data page that resolves the current operator in its load logic and passes that value into the report definition as a parameter.
Create a report definition on the target class and add a parameter such as Param.OperatorId and use that parameter in the report filter, for example pxCreateOperator = Param.OperatorId and then create a list data page that sources the report definition.
If you are only looking for current operator context, you can always reuse ‘D_pxOperatorDetails’ OOTB datapage. This lets all charts reuse the same source without referencing ‘OperatorID’ page directly in the Insight configuration.
So the wrapper is not a separate chart source in the sense of duplicating logic per Insight, it is the shared runtime-filtered source that all the charts can point to.
Additionally, the data page can default the report parameter to the logged-in operator and the Insight can expose the same operator field as a runtime filter so the user can switch to another permitted operator when needed. The important part is to back that with an allowed-operator list, such as direct reports or managed team members, so users can only view worklists they are authorized to access