We have configured an embedded attachment field on a table. However, we are facing an issue where, whenever a document is attached through this embedded field and the case is moved forward, an entry is created in the Data-WorkAttach-File class, but no corresponding entry is created in the Link-Attachment class.
Upon further analysis, we observed that Pega explicitly sets a parameter to “True”, which prevents the creation of a Link-Attachment record (refer to the attached screenshot with the highlighted code).
We would like to understand the following:
Why is the link creation intentionally disabled for attachments added through an embedded attachment field?
Since there is no extension point or configuration option to modify this parameter, is there a recommended approach to enable link creation in this case?
If we implement a custom solution to manually create entries in the Link-Attachment class, what potential issues or challenges could we face in the future (e.g., upgrade impact, attachment retrieval inconsistencies, or performance considerations)?
Activity rule which are referred: pzApplyPageInstructions (class Work-) step 3.9 where param skipLinkAttachment set as “true”
pzAttachUploadedFileForEmbedFields (@baseclass) Step 11 calling automation which use this above parameter
@AshutoshsinghWhat you mentioned is right that a Link-Attachment record is not created when you attachments in the embedded pages. However i want to understand few things,
What is the issue you are facing when you move ahead to next screen in the workflow if you don’t have the Link-Attachment entries ?
Is it a requirement that the all the embedded attachments also have to be seen attached to main case for preview/download purpose?
If your answer is yes, there it would be clutter of attachments on the case where it becomes difficult to figure out the difference between case level and data level attachments.
To maintain a good viewing experience you can utilize the Tabs on the case where you can create a view for showing up the table where you have added the entries and you will still have the facility of preview/download/open in new tab features for the attachment. This would ensure a clear distinction between the case level and data level attachments. In case of attaching these uploaded files into an email further, it would be easy for you to figure out where you can find the attachments rather going through the case level attachments with additional filters (if any). You can also write a local action on the case to show the embedded attachments list in a modal window as an alternative (less likely/inclined).
My assumption of this behaviour is may be to differentiate between the case and data level attachments, reduce the entries written to link-attachments table.
Checkout the image attached for the implementation of what is proposed above.
From the read-only view below are the capabilities for the attachments,
Image - Preview/Download/Open in New Tab - All are working
PDF - Preview(not working) / Download and Open in New Tab (Working fine)
Docx - Chrome Browser says cant preview / Download is working fine
Want to hear more about your requirement and the issue you are facing.
@Ashutoshsingh I believe this is by design. Those attachments are meant to be stored and viewed inline with the embedded data (not case data widget) so the appropriate Link- class instance is not created.
I’ve reached out to our teams who implemented this to confirm that is the case.
Business Outcome
Is this the underlying business outcome that is not met in this feature? The business user would like to see all attachments on embedded data in the attachments widget?
Customization/Extension
Yes, changing the way this feature works could have potential update impacts in the future, if the design of embedded data attachments or case attachments is ever changed. Just like any other customization or tweaking of OOTB rules, caution should be taken. However, if that did happen, I would expect this to be in the release notes for that update, which does help mitigate issues and plan for these changes.
@JayachandraSiddipeta :Thanks for the reply. We have changed the design and requirement as we need Link-Attachment to be present always because there is some logic need to be executed on the link-attachment entries.
