Create a text attachment on a record

The GlideSysAttachment.write() method creates attachments directly in the database without going through the UI attachment processor. Most developers trip up on character encoding — special characters, line breaks, and Unicode get mangled unless you base64 encode the content first. The platform expects binary data, so raw text strings often corrupt during the write operation, especially in non-English environments or when processing user-generated content with unpredictable characters.

When to use this

• When generating reports, logs, or data exports programmatically in server-side scripts
• When creating audit trails or documentation that needs to persist with a record
• When processing data transformations where the intermediate or final output needs to be saved as a file
• When integrating with external systems that require file-based evidence of processed records

When NOT to use this

• Don't use this for large files (>10MB) — use the Import Set API or external storage instead
• Don't use this in Business Rules on high-volume tables — you'll create database bloat and performance issues
• Don't use this for temporary data — attachments persist until manually deleted and consume database space
• Don't use this for binary content without proper encoding — use GlideSysAttachment.writeBase64() for images or documents

Key behaviors and gotchas

• The method returns the sys_id of the created attachment record, or empty string on failure — always check for success
• File names with special characters or spaces can cause download issues — sanitize with replace(/[\s:]/g, '_')
• Content-Type header affects how browsers handle downloads — use text/plain for readable files, application/octet-stream to force download
• Domain separation applies — attachments inherit the domain of the target record and may not be visible across domains
• ACLs on the sys_attachment table control attachment visibility — test with different user roles
• Base64 encoding increases file size by ~33% — factor this into storage calculations for large implementations