"document display" in UI builder does not work as expected

[fredrik_]

We have tried to show all of a records attachments in "document display" in a page in ui builder. if there is only one pdf then it seems to work, but if there is several pdfs then "document display 1" shows the title/name of pdf 1 but the body/content of pdf number 2 and vice versa. if there is more than 2 this also happens but sometimes one of the bodys/content does not show at all.

we used 2 and we hardcoded in sys id and this still happend.

what we want and need to do is to use an repeater that repeats a document display depending on how man y there are and show them next to eachother.
but since this still happend when we used 2 hardcoded values i do not believe it has anything to do with the repeater or the logic used to get the pdfs to ui builder.

we get diffrent outcomes if we reload the same page, sometimes it works like it should but most of the times not.

content type is always "application/pdf"

is there a known issue with document display or using several document display on the same page?
i did try a workaround using iframe and calling the pdf from there but this seemingly does not work either to show pdf in an iframe. i would prefer to use the "document display"

[Ravi Gaurav]

Hi @fredrik_ 

What’s working & supported

• The Document Display component is designed to show a single attachment (or document) for a given sys ID.

• The official doc (and community posts) show it being used in simple cases: one viewer, one attachment.

• The component can behave unexpectedly when it doesn’t find a valid attachment ID or isn’t properly bound. ServiceNow+1

Similarly, the newer “Attachment” component (for listing/uploading attachments) is documented reliably for multiple files, but not the Document Display for “repeaters” of many attachments. ServiceNow

Your description of the issue is very consistent with times when the component’s internal binding or rendering “gets confused”. Specific symptoms:

• With two or more PDFs, the component shows the title/name of file #1 but the content/body of file #2 (and vice-versa).

• When using two hardcoded sys IDs it still happens → so it’s less likely your repeater logic is faulty and more likely the component or its binding/render loop is.

• Reloading yields different outcomes (sometimes correct, sometimes wrong) → this suggests a race condition, caching, or rendering mis-alignment issue.

From the community post I found:

“The other issue I’ve seen is … when the component ‘loads’ if it doesn’t have an attachment ID, it seems to display a no file exists error … once you do that … it doesn’t seem to display again after that.” ServiceNow

“I ended up using an iframe … the only success I’ve had in keeping it contained is with a modal” (for the Document Display component) ServiceNow

So yes -you are observing one of the “quirky” behaviours.

[SivaniG]

Hi @fredrik_ ,

I managed to achieve to see "Images" in attachments using data broker and iframe component.

i dynamically set the source value to url as "

/sys_attachment.do?sysparm_referring_url=tear_off&view=true&sys_id='+id of attachment.

It was working for the images.

i will look into to show the pdf's as well.

If you wanted me to show how i achieved for images i will.

Thank you

[MaxMixali]

Short answer: yes—this is a known quirk when you place multiple “Document display” components on the same UI Builder page. What you’re seeing (title of PDF #1 with body of PDF #2, or empty canvases) is caused by how the viewer instance (PDF.js under the hood) and the component’s internal state are reused between renders. It’s most visible when the page hot-reloads, you use a repeater, or multiple instances mount nearly at the same time.

Below is a stable way to fix it, plus a few alternative workarounds.

---

Why it happens (in plain terms)

• The “Document display” component creates a viewer instance that isn’t always fully isolated per component.

• When multiple components render, their viewer state can race or collide, so the canvas for A ends up drawing B.

• Browser caching of the same download URL (attachment servlet) can worsen the mismatch.

• With a repeater, React/Now Experience may reuse the same DOM subtree unless you force a unique key, so the wrong PDF is “repainted” in a reused container.

---

Fix (robust pattern with a Repeater)

1. Query attachments first

   Add a Server Script data resource (or the “Attachment” data broker) that returns all sys_attachment rows for your record:

• Table: the record’s table (e.g., x_app_table)

• Record: the record’s sys_id

• Filter: content_type=application/pdf

Return an array like:

[
{ "sys_id": "…", "file_name": "…", "content_type": "application/pdf" },
…
]

1. Use a Repeater with a stable key

• Drop a Repeater in UIB.

• Items = the array from step 1.

• Key = item.sys_id (critical: this forces a unique mount per PDF).

1. Inside the Repeater, place ONE “Document display”

   Bind its props to the current item:

• Attachment sys_id / Document id = {{item.sys_id}}

• Content type = application/pdf

• Title = {{item.file_name}}

1. Force unique remount if you still see mixing

   Wrap the Document display inside a Container and set the Container’s Key (or id) to {{item.sys_id}}. This prevents any DOM reuse.

2. Cache-bust the URL (optional but helpful)

   If the component has a document URL property instead of an attachment id, build:

/api/now/attachment/{{item.sys_id}}/file?download=false&inline=true&v={{state.refreshKey}}

Where state.refreshKey = Date.now() you set once on page load (or whenever you “refresh”). This avoids the browser serving a cached blob to the wrong viewer.

---

If you are NOT using a Repeater (two hardcoded PDFs)

Even with two fixed “Document display” components, do this:

• Ensure each instance has:

  • A different bound attachment sys_id

  • A unique container key (e.g., a wrapping Container with key set to the same sys_id)

• Avoid toggling visible rapidly on either component right after load; let both mount cleanly.

---

About using an

<iframe>

as a fallback

• The attachment servlet will only render inline if Content-Disposition: inline is honored and CSP allows it.

• In UIB/Workspaces, CSP may block inline PDFs in iframes. If you try:

<iframe src="/sys_attachment.do?view=true&sys_id=<ID>"
sandbox="allow-same-origin allow-scripts"
style="width:100%;height:600px"></iframe>

• you might still be blocked by CSP or by the attachment response headers. This is why the native component is preferable.

---

Alternative workaround (very stable)

If the Document display component still cross-wires, switch to Attachment API + Object URL:

• In a Client Script (UIB controller), for each attachment:

  1. fetch('/api/now/attachment/<sys_id>/file', { headers: { Accept:'application/pdf' } })

  2. blob = await resp.blob()

  3. url = URL.createObjectURL(blob)

  4. Bind that url to a custom viewer (e.g., <embed type="application/pdf" src="{{item.url}}">)

• Give each viewer a unique key (the sys_id); revoke URLs on unmount.

This avoids shared viewer state entirely. (CSP permitting.)

---

Quick checklist to resolve your case

• Use a Repeater with key = item.sys_id.

• Inside, one Document display per repeater item.

• If the component offers a doc URL binding, append a cache-buster query param.

• Wrap the component in a Container with key = item.sys_id to force unique mount.

• Avoid conditional rendering that rapidly hides/shows them during initial load.

• If still flaky, use the Attachment API + embed approach.

---

Is this a known issue?

Yes—multiple PDF renders on the same UIB page have had race/instance isolation issues across several recent releases. The patterns above (unique key per instance + cache-bust + clean mount) are the accepted workarounds until the component isolation is fully hardened.