We are using Pega Infinity ’25.1.1 and have a requirement to implement Attachment search by customizing the Global Case Search.Currently, attachments are being retrieved by enabling the search setting “Include attachments for all platform applications.” With this configuration, the Global Case Search results include a .pzAttachments (Page List) under each case.
However, the issue is that we are unable to add any custom properties to the .pzAttachments list, such as CreateDateTime or UpdatedOperator.We attempted to resolve this by creating Custom Search Properties at both the Link-Attachment and Data-WorkAttach-File layers, but the additional properties still do not appear in the .pzAttachments results.
I also tried to add custom property in Work- layer as well, its not getting added to the search results.(Can be search, but not able to see in results)
Please suggest the optimal approach to include additional/custom properties within the .pzAttachments list for attachment search results in Global Case Search?
With .pzAttachments approach you are running into a platform constraint: the .pzAttachments list that Global Case Search returns is a fixed, engine-generated structure. It’s populated by the search subsystem (SRS/Elasticsearch) when you enable “Include attachments for all platform applications”, but it does not automatically surface arbitrary, custom attachment fields—even if those fields are indexed and searchable. That’s why your Custom Search Properties on Link-Attachment and Data-WorkAttach-File make the fields searchable, yet they still don’t appear in .pzAttachments - OOTB for Global Search results view.
D_pyWorkSearch (and its underlying pyWorkSearch report definition) lets you control which case-level columns are returned by the search API when you invoke it via pxRetrieveSearchData or when a search gadget is configured to use that RD— IMO it might not change the composition of the nested .pzAttachments() list that Global Case Search returns - please try and share your observations. If this approach works this would be the simplest way to address your problem statemnt - otherwise you can try the below approach.
Build a dedicated Attachment Search (UI + DP + RD) on SRS
Make the fields indexable & returnable : Create Custom Search Properties (CSP) for the classes you search (usually Link-Attachment for linkage metadata and, if needed, Data-WorkAttach-File for file metadata).
Create an RD that runs on the search index: Build a Report Definition on Link‑Attachment (join to Data-WorkAttach-File and Work class keys when necessary). Include Column source entries for each field you marked as returnable in CSP
Call SRS via pxRetrieveSearchData
Build the Constellation view that lists attachments : Bind your List DP to a table and show CreateDateTime, UpdatedOperator, filename, category, case ID, etc. This approach mirrors how Pega recommends customizing search gadgets—you control columns by controlling the RD that the gadget/query uses.
Thanks for your Suggestion Vikas, We can go with dedicated Attachment search, but the problem is ,we got the requirement to search Work attributes like case id ,customer Name and relevant Attachments should be displayed. Also, We need to show work attributes such as Customer Name, Entity , etc., Could you please suggest further on this.
If you must keep using the global search bar and its default search results, treat .pzAttachments as a skeleton and build your additional fields around it.
Let SRS perform the case search as usual.
Global search (and search gadgets) ultimately call the pxRetrieveSearchData API against SRS/Elasticsearch. You control behavior via parameters or by adjusting the report definition that backs the call.
Hook into the post fetch extension point.
Use the extension hooks around search — leverage pySearchWorkParams to adjust search parameters and pyFilterSearchResults to filter/enrich after results return.
Batch-ookup attachment metadata and merge it back.
Iterate through each result rows .pzAttachments() and collect the Link-Attachment identifiers or attachments handles.
Run a single, batched Report Definition against Link-Attachment join to Data-WorkAttach-File if you need file metadata to fetch CreateDateTime, pxUpdateOperator, etc. Ensure those fields are returnable in SRS via Custom Search Properties (CSP) so you can retrieve them efficiently from the index as needed.
Property-Set the fetched values back into each results .pzAttachments(n) pages.
.pzAttachments(n).CreateDateTime = RDResult.CreateDateTime
Render these extra fields in a preview/details panel you control.
In a nutshell
User types → Pega SRS returns → pyFilterSearchResults → Batch RD fetch → Enriched pzAttachments → UI preview shows full metadata
Since you would rely on batch lookups - keep a tab on performance.
Also, You must handle external repositories ie.,if attachments are stored on say CMIS:Pega cannot index them in SRS -Only metadata stored in DB is retrievable
Thanks for your suggestion — I really appreciate it. Could you also share some insights on batch lookup? Does “batched report definition” refer to a report with pagination?
Also, when I try to create an RD with the data retrieval preference set to “Use Search Data” for Link Attachment (attempting to configure it as SRS returnable via custom search properties), I’m getting a warning “Class ‘Link-Attachment’ is not indexable. It is defined in the search data model only.” Is there a way to mitigate or resolve this?