However, when an end user selects this email template in the End User Portal, the signature image is not displayed correctly. Instead, it appears broken or is not rendered as expected.
This is a fairly common issue in Pega email templates and is usually not specific to SIAA. The root cause is typically how the image is referenced rather than the email template itself.
How is the image referenced? - This is the first thing to verify.
If the signature image is:
Attached as a local file (copied from your computer) → it generally won’t render for other users or in the portal.
Referenced with a relative URL (e.g., /prweb/…) → it may work in the Dev Studio but fail in the End User Portal or in the recipient’s email client.
Stored as a binary/file in Pega → the generated URL may require authentication, which the email preview or recipient cannot access.
The browser’s developer tools (Network tab) can help identify whether the image request is returning a 404, 403, or another error.
End User Portal limitations
The End User Portal generally renders the email body using an HTML component. If the image URL-
requires an authenticated Pega session,
uses a temporary resource URL, or
points to a resource unavailable from the portal context,
the image will appear broken.
So while the portal doesn’t intentionally block images, it can only render images that are accessible from the current context.
Overall, the most reliable solution is to host the signature image at a publicly accessible HTTPS URL (or an internally accessible URL if recipients are within your organization) and reference it with an absolute URL.
@AJRangarh Thank you for your detailed explanation.
I was able to resolve the issue. The solution was to use Base64-encoded images for the signature instead of referencing the image through a URL. After embedding the images in Base64 format, they rendered correctly in the End User Portal as well as in the generated email.
