[Constellation CS '25] What is the supported extension surface of the email composer / EmailContainer widget?

User Experience
, ,
1

Hi all,

We’re assessing how to deliver Inbound Email on Constellation Customer Service '25 for a banking client. We’re deliberately designing for the Constellation way of working rather than porting their old UI-Kit screen one-to-one, so we’re genuinely ** open to adapting the requirements ** if there’s a better supported pattern: our problem is however that we can’t find the extension surface to reach the underlying outcomes.

The outcome we need (banking compliance + reducing agent error on outbound email): the agent must not be able to expose or alter certain parts of an outbound message (the recipients and the original thread) and the message must carry the correct brand identity.

Concretely:

  • Hide the Cc/Bcc fields (and the “Cc Bcc” reveal links) so agents cannot add recipients
  • No file attachments from the composer (links only) - ideally no paperclip at all
  • the quoted/original thread must not be editable, only the new reply
  • a “Brandline” selector in the content area that drives the signature and the From identity

What we’ve already explored:

  • D_pxEmailComposerMetadata + its extension pyGetEmailComposerMetadata: lets us set values (From, recipients, body) but not hide/disable fields or the paperclip in the view
  • pySetRepliedEmailContentTemplateV2 / pySetForwardEmailContentTemplateV2 + the reply Correspondence rule: fine for body content; contenteditable="false" makes the quoted block visually read-only but is bypassable via browser Dev Tools.
  • Server side, pzValidateSendRequest already rejects outbound attachments (using security mechanisms) but the paperclip stays visible in the UI.
  • We found no configuration, view rule or extension point that hides Cc/Bcc or the paperclip, or that renders an editable custom field inside the EmailContainer widget. The only path we see is rebuilding an Email Container DX component, which we’d rather avoid.

Questions:

  1. Is there a supported way (configuration, view rule or extension point) to hide/disable the Cc/Bcc fields and the attachment paperclip in the Constellation email composer?
  2. Is there a supported, robust way to make the quoted thread genuinely read-only?
  3. Can the EmailContainer widget be extended to display/edit a custom field such as a Brandline?
  4. If these aren’t meant to be customized, what is the recommended Constellation pattern to achieve the same outcomes? How should we rethink our needs?

Thanks a lot!

@VikasRaidhan @Kamil_Janeczek @MarcCheong , any guidance would be much appreciated.

2
  1. CC/BCC/Attach icons can’t be hidden.
  2. ‘Quoted original thread’ - One way to do is to turn off ‘Access complete email chain’. The downside would be no quoted text at all.
  3. Template selction - We recently exposed the reply template combobox to support multi level nesting and fill content using external templates.
3

Thanks @VikasRaidhan for your feedback.

  1. CC/BCC: we are exploring the option to simply remove them during the Send from within one of the PostMessage extension points
  2. We might be ok with displaying email thread when viewing email and removing it (turn off ‘Access complete email chain’) when replying since we don’t want the thread to be send to the client anyway.
  3. When you say “recently” are you referring to CS '25? or should I explore coming '26 for new enhancements?
4
  1. While I agree there’s no alternative, won’t removing after-the-fact cause confusion?
  2. Caution on ‘Access complete chain’ off : Even though the email is not visible on UI, the trail is still constrcuted in the back-end and sent to end-user. It is, however, possible to remove the trail from the body templates being used.
  3. It is being done in patch version 25.1.4 and 26.1.1 which are still very far out right now. There’ll be a hotfix on 25.1.2 that has that change.
5
  1. Agreed but if we cant hide/disable those fields it is better than allowing to violate security policies…
  2. I’m trying to be crystal clear on your comment: do you mean that it is included in the data page content being returned to the browser BUT the section (custom html) in charge of displaying the reply does not display. In other words, the email thread is not displayed but technically accessible from the browser. Am I getting this right?
  3. Good to know, since we are in the early stage of Constellation assessment (if we move it’ll be in 2027 not before) I’m happy to get a sneak peek or screenshots of this reply template combobox improvement.
6

On the template and quoted text -

When you click on ‘Reply/ReplyAll/Forward’, you’ll get a blank email composer. The CSR then types their email (they don’t see any trailing mail). When they click on ‘Send’, the typed email is sent to server and then Pega constructs the entire email chain behind the scenes and sends it to email recipient (an end-user).

Example, let’s say there’s an email conversation with 3 back and forth

Email 1 (Initial email from end-user)
Email 2 (CSR's reply to end user)
Email 3 (Response to CSR from end user)

Now, when CSR hits Reply, they type in Email 4 in composer. They only see Email 4 which they are typing. But, an end-user in their inbox see the email chain -

Email 4
Email 3
Email 2
Email 1