Pega Pulse in Constellation – How to Hide Attachment Upload Option?

General
,
1

Hi Experts,

I have a relatively simple requirement related to Pega Pulse in Constellation.

We want to keep the standard Pulse functionality available, but hide/disable only the attachment upload option (attachment icon/upload capability) from the Pulse UI.

I quickly checked the available configurations and documentation, but I could not find any OOTB setting or configuration to control this behavior.

Before the discussion goes in the direction of “why hide it” or “can the business requirement be changed” — that discussion has already happened internally, and the requirement is confirmed and valid from the client side. The main focus here is understanding the technically recommended Constellation approach for such customization.

What is the recommended approach from a Constellation architecture perspective?

- Is there any supported way to hide the attachment upload option within the standard Pulse component?

- Are there any extension points available for this?

- Or is the expectation to build a custom DX component/custom Pulse implementation to gain full control over the UI behavior?

My concern is that for such a small UI requirement, rebuilding the entire Pulse experience using custom DX components feels quite heavy.

Interested to know how others have handled similar requirements and what Pega’s recommended approach is.

Thanks.

2

Sorry I really need to ask, why hide it ? :slight_smile:

What is the risk, potential issue user attaching file to pulse even if it not needed/required?

Is it a major priority requirement?

3

Thanks Kamil for your quick response.

The main reason is related to document governance and storage architecture.

The client does not want users to upload documents through Pulse, even accidentally, because Pega is not being used as the enterprise content storage system in this implementation. Documents are expected to go through a different approved document/content management flow and external storage system.

Also, Pulse attachments do not automatically become standard case attachments by default. To align them with the enterprise document management process, additional custom logic would need to be implemented for:

- converting Pulse attachments into case attachments,

- routing/storing them into the external content management system,

- and governing them through the standard document lifecycle.

The client wants to avoid this entire path and therefore prefers not to expose the upload capability within Pulse at all.

That said, the discussion around whether the upload feature should or should not be hidden can continue separately. My main objective here is to understand what Pega’s recommended Constellation approach is for such requirements.

For example:

- should customers fully rebuild/replace the feature using custom DX components,

- or is there some lighter supported extensibility approach expected for these kinds of UI customizations?

We are seeing similar situations in other areas as well, where small but important enterprise requirements are not directly supported OOTB. Examples include:

- showing environment labels on the portal,

- extending the attachment modal dialog with additional metadata fields,

- displaying additional/different case fields in global search results,

- and similar UX-level customizations.

So this question is more from a broader Constellation architecture and extensibility perspective.

4

@Rekha_Rani can you support us here please?

5

My 2 cents:

It’s worth stepping back and understanding the intent of Pulse before going down the customization path.

Pulse is designed as a real-time collaboration tool between teams — it is not intended to serve as a case-level attachment. These are two fundamentally different concepts.

For example, consider a scenario where a shipment is delayed. A user might attach a UPS/FedEx screenshot in Pulse and tag the relevant shipment processing team member to expedite the issue. In this context, the attachment serves as contextual collaboration, not as a formal case document.

So before investing effort in a custom DX component to hide the attachment option, I would recommend having a conversation with the client about the intended purpose of Pulse. Understanding this distinction may help reframe the requirement and potentially avoid unnecessary customization altogether.

That said, if the requirement remains firm after that discussion, a custom DX component would be the alternative — but it’s worth ensuring the client is fully aware of the trade-off before heading in that direction.

6

Hi @RameshSangili , I agree with your point regarding the benefits of supporting attachments in Pulse. However, I also echo @Aasif_Qureshi suggestion to implement this capability as an extensible option.

In several of my past projects within the government and banking sectors, we wanted to utilize Pulse for conversations but needed to restrict attachments due to strict compliance or security requirements. To achieve this, we were forced to either build a custom solution or override the Out-of-the-Box (OOTB) Pulse section in our application layer to remove the attachment feature. Unfortunately, overriding OOTB components consistently introduced maintenance overhead and issues during upgrades.

Pulse is a powerful tool for seamless communication. Providing the flexibility to toggle or extend the attachment feature would be an excellent enhancement for enterprise compliance.

7

Hi Arif - The feature is not available in constellation where you can disable the attachment in Pulse. Can you please raise a feedback request with business use case.

8

Thank you @Kamil_Janeczek @RameshSangili @Gaurav25 and @Rekha_Rani for your responses!
I will submit a feedback request.

9

Hi,

This response on another post might help you to hide the Attachment upload option in Pulse.

We are facing the same constraint.

It’s a non standard approach, but it might do the “trick”.

10

Thank you for sharing Arnaud!