Pega 24.1 Constellation - Looking for Alternative Approach for Attachments Type Field in Embedded Data

Hi Team,

We are currently on Pega 24.1 Constellation and have a requirement where an embedded data fields needs to contain an attachment field, similar to the example shown in the image below.

However, when attempting to model this, we are unable to define an Attachment Type field within a Data Class. Based on the documentation, support for attachment-type properties in data objects appears to be available only from Pega 25.1 onwards.

Since we need to support this capability in 24.1 implementation, we are looking for any workaround, alternative design approach, or best practice that can help achieve similar functionality.

Any suggestions or guidance would be greatly appreciated.

@MarcCheong @Kamil_Janeczek @RameshSangili

Thanks.

As the case type class allows creation of an Attachment property, we created a single-page Attachment property in the case class and then created an embedded data property with its Page Definition pointing to the case type class.

However, when configuring the embedded data Table view, the Attachment property is not available for selection and does not appear in the list of fields that can be added to the table view columns.

Has anyone encountered this behavior before, or is there a supported approach to expose Attachment properties within embedded data/table configurations in Pega 24.1?

@MarcCheong @Kamil_Janeczek @RameshSangili

@SSrinivas actually, this was supported from Infinity '24.2. I would strongly recommend moving this the next minor version to take advantage of this.

I have seen prior to this feature some different ways of doing it, it usually boiled down to a URL field being placed in the embedded data, which linked off to the attachment. It wasn’t the nicest of solutions, so I would be taking advantage of what Pega provides in '24.2+

@MarcCheong , Upgrade is not feasible at this stage due to the planned deliverables and go-live near by. Can you share more details on the approach you suggesting before 24.2

Agreed @MarcCheong! @SSrinivas - Patch upgrades are seamless to be honest. We recently did couple of patch ugprades in 24 and 25 versions and it is less than a week effort. I’m not sure about the complexity of your applicataion, but it should be seamless in my opinion.

Thanks @RameshSangili @MarcCheong

Upgrade is not easy for us because the same instance has a Complex application, so getting upgrade would not possible. Any alternate technical options you recommend for this?

@SSrinivas update would make more sense, I would strongly be recommending my client wait for this update to take advantage of the new feature (over trying to build something custom yourself).

As for work around, I’ve seen some projects prior to this store the attachment externally (sharepoint) and then use a URL field backed by a calculation / data transform to derive the attachment itself. The UX is very different to what we provide in 24.2, so again, another reason I would be recommending waiting until you can take advantage of this feature.

@MarcCheong, I understand that an upgrade would simplify the implementation. However, the business is not planning an upgrade until October. As a last resort, we developed a reusable DX component that invokes the Upload API and stores the returned attachment IDs in a property. During post-processing, a Data Transform iterates through the list of attachment IDs and converts them into attachments from temp attachment class. In essence, we have explicitly implemented the same attachment creation process that Pega performs behind the scenes.