sys_attachment Table — ServiceNow Reference

Table Reference/sys_attachment

The sys_attachment table stores metadata for files attached to any ServiceNow record. Part of the Platform module, it holds file information like name, size, and content type, but not the actual binary data. The most important thing to know: it uses table_name and table_sys_id fields to reference parent records without foreign key constraints.

What This Table Is

The sys_attachment table stores metadata for every file attached to ServiceNow records. When users drag files onto forms or attach documents via email, this table captures the file name, size, content type, and relationship to the parent record. The actual binary file content lives in the sys_attachment_doc table, linked via the attachment's sys_id.

This table belongs to the Platform module and supports file attachment functionality across all ServiceNow applications. Unlike domain-specific tables, attachments can be linked to any record in any table through a flexible reference mechanism. The attachment system processes files uploaded through the web interface, mobile apps, email processing, and REST API calls.

The sys_attachment table doesn't extend any parent table and has no child tables extending it. Instead, it uses a polymorphic relationship pattern with table_name and table_sys_id fields to reference any record in the system. This design allows attachments to work uniformly across incidents, changes, knowledge articles, and custom applications.

Large enterprises typically see hundreds of thousands to millions of attachment records, with significant volume growth from email processing and mobile uploads. Each attachment record is small (under 1KB), but queries filtering by table_name and table_sys_id perform well due to compound indexing. Performance degrades when querying by file_name or content_type without including the table reference fields.

When You'll Script Against This Table

You'll script against sys_attachment in Business Rules when records are deleted (to clean up orphaned attachments), Script Includes for custom attachment processing, and Scheduled Jobs for attachment maintenance. Email processing scripts frequently query this table to handle inbound attachments. REST API integrations use it when uploading or retrieving file metadata.

The attachment_admin role controls full access, while itil provides read/write for most records. ACLs evaluate based on the parent record's permissions - users who can read an incident can typically read its attachments. Scoped applications inherit attachment access from their parent record permissions.

Common scripting patterns:

Counting attachments on a record before allowing state changes
Copying attachments when cloning or creating related records
Filtering attachments by file type for processing workflows
Building custom attachment viewers or download handlers
Auditing attachment activity for compliance reporting
Implementing custom file size or type restrictions
Cleaning up attachments when parent records are archived

Table Gotchas

⚠️

The table_name and table_sys_id fields are just strings with no foreign key constraints. ServiceNow won't prevent you from creating attachments pointing to non-existent records or invalid table names.

The state field defaults to 'available' but can be 'pending' during upload or 'not_available' if processing fails

⚠️

Deleting sys_attachment records doesn't automatically delete the corresponding sys_attachment_doc records, creating orphaned binary data that consumes storage.

The size_bytes field stores the original file size, not the compressed storage size in the database
Queries without table_name in the filter can trigger full table scans on large instances

⚠️

The content_type field may not always match the actual file content - it's set from HTTP headers or file extensions, which can be spoofed or incorrect.

ACL evaluation happens at query time based on parent record access, not when attachments are created

Free Newsletter

Enjoying this? Get one deep-dive per week.

Join 1,000+ ServiceNow pros — scripts, GlideRecord patterns, Flow Designer techniques, and career moves. Free.

The sys_attachment_doc table is the essential companion, storing the actual binary file content. Every sys_attachment record should have a corresponding sys_attachment_doc record with the same sys_id. The sys_email_attachment table references attachments created through email processing, linking them to specific email records.

Any table can have attachments through the polymorphic relationship, but task and its extensions (incident, change_request, problem) are the most common attachment targets. Knowledge base articles (kb_knowledge) and catalog items (sc_cat_item) also frequently store attachments.

When building reports or integrations, developers often join sys_attachment with parent tables to analyze attachment patterns by record type, urgency, or business category. The sys_user table connects through standard audit fields to track who uploaded attachments, while sys_audit provides detailed attachment creation and deletion history for compliance requirements.

Chrome Extension

Sourdough: ServiceNow Monitoring and Analytics

A Chrome extension for ServiceNow Admins and Developers with essential tools, analytics, graphs and monitoring features.

Instance HealthGraphs & ChartsAPI HealthDeveloper ToolsQuick SearchInstance Switcher

Add to Chrome

Free to install. Pro $5/month after a 14-day no-card trial.
Pro requires the ServiceNow admin role. Upgrade inside the extension.

Overview

Tasks

CMDB

API

Metrics

Monitor

Internals

Instance:sourdoughdev·Version:Yokohama

Instance StateONLINE

System StatusFully Operational

Session Timeout90 minutes

Logged-In Sessions2 (20 active)

Build Nameyokohama-12-18-2024_p1

IP Address10.159.128.43

Instance HealthHealth Score: 90%

🔥 5dSourdough (Chrome Plugin)Dark Mode

Key Fields

Column	Type	Label	Notes
table_name	string	Table name	Name of the table containing the parent record. No foreign key constraint - can contain invalid table names.
table_sys_id	string	Table sys ID	sys_id of the parent record this attachment belongs to. No referential integrity - parent record may not exist.
file_name	string	File name	Original filename as uploaded. May contain characters that cause issues in file systems or URLs.
content_type	string	Content type	MIME type of the file (e.g. 'image/jpeg', 'application/pdf'). Based on file extension or HTTP headers, not actual content analysis.
size_bytes	integer	Size in bytes	Original file size in bytes before any compression. Doesn't reflect actual storage footprint in database.
size_compressed	integer	Compressed size	Compressed file size in bytes as stored in sys_attachment_doc. Often significantly smaller than size_bytes.
state	choice	State	Processing state: 'available', 'pending' (during upload), or 'not_available' (processing failed). Defaults to 'available'.
hash	string	Hash	SHA-256 hash of file content for integrity checking and duplicate detection. Calculated during upload.
compression	choice	Compression	Compression method used for storage: 'gzip' or 'zip'. Affects how binary data is stored in sys_attachment_doc.
average_image_color	string	Average image color	Hex color code of average image color, calculated for image files only. Used for UI previews and theming.

Common Queries

Get all attachments for a specific record

// Most basic query - get all attachments for an incident
var gr = new GlideRecord('sys_attachment');
gr.addQuery('table_name', 'incident');
gr.addQuery('table_sys_id', current.sys_id);
gr.orderBy('sys_created_on');
gr.query();

while (gr.next()) {
    gs.info('Attachment: ' + gr.file_name + ' (' + gr.size_bytes + ' bytes)');
}

Find large PDF attachments on active incidents

// Find PDF files over 5MB on active incidents for cleanup
var gr = new GlideRecord('sys_attachment');
gr.addQuery('table_name', 'incident');
gr.addQuery('content_type', 'application/pdf');
gr.addQuery('size_bytes', '>', 5242880); // 5MB in bytes
gr.addQuery('state', 'available');
gr.query();

while (gr.next()) {
    // Join to incident to check if still active
    var inc = new GlideRecord('incident');
    if (inc.get(gr.table_sys_id) && inc.active) {
        gs.info('Large PDF on active incident: ' + inc.number);
    }
}

Copy all attachments from one record to another

// Copy attachments when cloning a change request
function copyAttachments(fromTable, fromSysId, toTable, toSysId) {
    var gr = new GlideRecord('sys_attachment');
    gr.addQuery('table_name', fromTable);
    gr.addQuery('table_sys_id', fromSysId);
    gr.query();
    
    while (gr.next()) {
        // Use GlideSysAttachment API for proper copying
        var attachment = new GlideSysAttachment();
        attachment.copy(toTable, toSysId, gr.sys_id);
    }
}

copyAttachments('change_request', source.sys_id, 'change_request', target.sys_id);

Count attachments by content type across all tables

// Aggregate query to analyze attachment types across the instance
var ga = new GlideAggregate('sys_attachment');
ga.addQuery('state', 'available');
ga.addAggregate('COUNT');
ga.addAggregate('SUM', 'size_bytes');
ga.groupBy('content_type');
ga.orderByAggregate('COUNT');
ga.query();

while (ga.next()) {
    var count = ga.getAggregate('COUNT');
    var totalSize = ga.getAggregate('SUM', 'size_bytes');
    gs.info(ga.content_type + ': ' + count + ' files, ' + totalSize + ' bytes');
}

Wrong way vs right way to find attachments by filename

// WRONG: Query by filename only - causes full table scan
// var gr = new GlideRecord('sys_attachment');
// gr.addQuery('file_name', 'CONTAINS', '.pdf');
// gr.query();

// RIGHT: Always include table_name when possible
var gr = new GlideRecord('sys_attachment');
gr.addQuery('table_name', 'incident'); // Use index
gr.addQuery('file_name', 'CONTAINS', '.pdf');
gr.addQuery('sys_created_on', '>', gs.daysAgoStart(30)); // Limit time range
gr.query();

while (gr.next()) {
    // Process results efficiently with indexed query
}

Test Your Knowledge

Quick 3-question quiz — see how your ServiceNow skills stack up.

Question 1 of 3Performance

A list view on a table with millions of records is slow. Best fix?

Select an answer to continue

sys_attachment