Archive attachment is working but not showing on the ar_custom_table record

[UTSAV KUMAR JAI]

Hello Everyone,

Currently, I am archiving incident records along with their attachments.
Once the archiving process is complete, I am able to see both the record details and the attachments in the ar_incident table.

When I perform the same process on any custom table, after archiving the record, I do not see the attachment in the corresponding ar_custom_table archive table.

What could be the root cause of this issue?

Thanks in advance,
Utsav

[Naveen20]

The problem is that ar_sys_attachment_doc doesn't exist in your system — and that's the critical piece.

What's happening: sys_attachment stores the attachment metadata (file name, content type, table reference), while sys_attachment_doc stores the actual binary content in chunks. Your archive rule successfully moves the header record to ar_sys_attachment, but when it tries to archive the binary chunks from sys_attachment_doc, it fails silently because ar_sys_attachment_doc doesn't exist as a target table.

This is why you see the attachment metadata in ar_sys_attachment with the correct table name and sys_id, but the archived record shows no downloadable/viewable attachment — the file content simply isn't there.

For OOTB tables like Incident, ar_sys_attachment_doc already exists because the platform provisions it. In your environment, it appears it was never created — possibly because no OOTB archive rule that includes sys_attachment_doc has ever run, or it was skipped during instance setup.

To fix this, I'd suggest checking a few things:

First, confirm the sys_attachment_doc chunks for this attachment still exist in the live sys_attachment_doc table — they should, since the archive would have failed for that part. Filter by the sys_attachment sys_id from your ar_sys_attachment record.

Second, check whether creating ar_sys_attachment_doc manually resolves it. In some versions, the archive engine auto-creates the ar_ table on first run, but if it can't (due to permissions or scope restrictions), it fails silently. You may need to work with a platform admin to ensure the table gets provisioned — sometimes running an OOTB archive rule (like Incident's) that includes sys_attachment_doc in its related records will trigger the table creation.

Third, once ar_sys_attachment_doc exists, re-run the archive for a test record and verify that both the header and the doc chunks land in their respective ar_ tables. At that point the archived record form should display the attachment properly.

The empty "Attachments" section you're seeing on the form (Point 2) should also resolve itself once the binary content is actually present in ar_sys_attachment_doc — the platform looks up archived attachments by joining ar_sys_attachment to ar_sys_attachment_doc, and without the doc table, there's nothing to render.

[UTSAV KUMAR JAI]

Hello @Naveen20 

I have created a PDI account. I tried archiving records of an out-of-box(incident), custom table(created by me) and another existing table in non-global application scope using the archive rule without even adding the archive related records in any of them but still attachments are visible on archived records.

Even though the ar_sys_attachment_doc table not present in PDI of Zurich version. Then, how come it is working in PDI.

Thanks in Advance
Utsav

[Naveen20]

What your PDI proves is that attachments don't need to be archived at all to be visible on archived records. On the PDI, without any Archive Related Records configured, the attachments simply stay in the live sys_attachment and sys_attachment_doc tables. When you open the archived record, the platform resolves attachments by querying the live attachment tables using the original table_sys_id — and since the attachments are still there, they display fine.

The problem isn't missing configuration — it's that the Archive Related Records are configured.

Here's what's happening in the original environment: because you have those two Archive Related Records entries for sys_attachment and sys_attachment_doc, the archiver moves the attachment header from live sys_attachment into ar_sys_attachment. It then tries to move the binary chunks from sys_attachment_doc into ar_sys_attachment_doc, but that table doesn't exist — so the chunks either stay orphaned in the live table or get lost. The end result is that the attachment metadata exists in the archive but has no binary content backing it, and it's also been removed from the live tables so the archived record form can't find it there either.

fix  — remove those two Archive Related Records entries from the custom table's archive rule (the sys_attachment and sys_attachment_doc rows). Let the attachments stay in the live tables, just like your PDI behaves. The archived record will then resolve them naturally.

If the goal is to eventually archive attachments too (for storage savings), then both ar_sys_attachment and ar_sys_attachment_doc need to exist, and the platform's archive viewer needs to be able to query both. But unless storage is a pressing concern, leaving attachments in the live tables is the simpler and more reliable approach.

[prabhakarku]

Hi @Naveen20,

I Tried creating a new table ar_sys_attachment_doc but it reverts the name back to u_ar_sys_attachment_doc. How to fix this?

[Naveen20]

@prabhakarku  That is expected for newly added tables and columns getting u_ added before
Can you try adding from Servicenow studio once.