What This Table Is
The sys_attachment_doc table stores the actual binary content of files attached to records throughout ServiceNow. When you upload a file, ServiceNow creates a record in sys_attachment with metadata, then chunks the binary data into one or more sys_attachment_doc records. This chunking prevents database performance issues with large files.
Owned by the Platform module, this table supports attachment functionality across all ServiceNow applications. Every file upload—from incident screenshots to knowledge base documents—flows through this storage mechanism. The table works as a key-value store where the sys_attachment_id field references the parent attachment metadata.
This table doesn't extend any parent table and has no child tables extending it. It's a standalone storage mechanism with a direct many-to-one relationship to sys_attachment. Large files get split into multiple chunks, each as a separate record with an incrementing position value.
In large enterprises, this table can contain millions of records. Each chunk is typically 1MB or smaller, so a 10MB file creates roughly 10 records. The sheer volume makes direct queries expensive—ServiceNow provides the GlideSysAttachment API specifically to handle the complexity of reassembling chunks into complete files.
When You'll Script Against This Table
Most developers never directly query sys_attachment_doc because the GlideSysAttachment API handles chunk assembly automatically. You might script against it in Script Includes building custom file processing utilities, Business Rules that need to examine binary content patterns, or background scripts cleaning up orphaned attachment data. Administrative scripts for storage analysis also query this table to calculate actual disk usage.
Access requires the admin role for direct table access, though scoped applications can access it within their scope. The data field containing binary content is restricted and won't appear in standard list views or reports for security reasons.
- Calculate actual storage used by attachment records across instances
- Clean up orphaned binary chunks when parent attachments get deleted improperly
- Build custom file processing utilities that need chunk-level control
- Analyze binary content patterns for security scanning or file type validation
- Debug attachment upload failures by examining partial chunk data
- Generate storage reports showing attachment size distribution by table or user
- Archive large attachment data to external storage systems
Table Gotchas
The data field contains binary content and can cause JavaScript memory errors if you try to manipulate it directly. Always use GlideSysAttachment API methods instead.
Querying without proper indexing can timeout. Always filter by sys_attachment_id first, then by position if needed. Never query the data field directly.
- The
positionfield starts at 0, not 1. Small files have only position 0, while large files increment from there. - Deleting
sys_attachment_docrecords directly will corrupt attachments. Always delete through the parentsys_attachmentrecord or use the API. - The table has no ACLs on individual records—security is enforced through the parent
sys_attachmentand its target record.
COUNT() queries on this table can be extremely expensive in large instances. Use GlideAggregate with proper filters or query sys_attachment instead for attachment counts.
- Chunk size is determined by instance configuration and can change over time, so don't hardcode expectations about
datafield length.
Enjoying this? Get one deep-dive per week.
Join 1,000+ ServiceNow pros — scripts, GlideRecord patterns, Flow Designer techniques, and career moves. Free.
Related Tables
The primary relationship is with sys_attachment, which stores attachment metadata like filename, content type, and file size. Every sys_attachment_doc record references exactly one sys_attachment record through the sys_attachment_id field. When building reports or cleanup scripts, you typically join these two tables to get both metadata and storage information.
Through the sys_attachment parent, you often query related tables like incident, kb_knowledge, or change_request—any table that accepts attachments. The sys_user table connects through sys_attachment.sys_created_by when analyzing which users upload the most attachment data. Administrative queries often span all these tables to generate comprehensive storage reports by user, table, or business function.
