Attachments and the Attachment API
Quick answer
Read, write, copy and validate attachments from script and from integrations.
Key takeaways
- Use GlideSysAttachment or the REST API, never the raw tables
- copy is the supported way to move files between records
- Validate type and size on anything user supplied
- Attachments consume storage, include them in retention plans
How attachments are stored
Attachment metadata lives in sys_attachment with the content chunked in sys_attachment_doc. Never touch those tables directly, use GlideSysAttachment or the Attachment API so chunking, size limits and permissions are handled.
Script examples
The common operations are copy, write and read.
var gsa = new GlideSysAttachment();
// copy every attachment from one record to another
gsa.copy('incident', sourceId, 'problem', targetId);
// write a generated file
var id = gsa.write(gr, 'summary.txt', 'text/plain', body);
// read text content
var text = gsa.getContent(attachmentGr);Inbound from integrations
The REST Attachment API accepts binary uploads against a table and sys_id.
- Validate the content type, do not trust the extension
- Set a maximum size property and enforce it in the flow or script
- Scan or restrict types where users upload to public facing forms
- Attachments count toward instance storage, archive old records
Want to learn this properly?
Our live, instructor-led ServiceNow Training covers this hands-on, with real projects and a certification path.
Check your understanding
Which class handles attachment operations in script?
- A. GlideRecord
- B. GlideSysAttachment
- C. GlideFile
- D. GlideDocument
Show answer
B. GlideSysAttachment
GlideSysAttachment covers copy, write, read and delete.
Why avoid writing to sys_attachment_doc directly?
- A. It is read only
- B. Content is chunked and managed by the API
- C. It is deprecated
- D. It has no index
Show answer
B. Content is chunked and managed by the API
The API handles chunking, size and permissions correctly.