Interview question - How to restrict users from uploading attachments in ServiceNow?

[The Matrix]

Hi All,

How do we restrict users from uploading attachments in ServiceNow? What are the different ways? 

Thank you!

[pr8172510]

Hi @The Matrix,

There are several ways to restrict users from uploading attachments in ServiceNow, depending on the requirement

1. ACLs (Recommended for security)

• Configure ACLs on the Attachment [sys_attachment] table to control who can create, read, write, or delete attachments.
• This is the preferred approach when access should be enforced based on roles or other security conditions.

2. Business Rules

• Create a Before Insert Business Rule on sys_attachment.
• Validate conditions such as the current user, target table (table_name), target record (table_sys_id), or record state.
• If the upload isn't allowed, use current.setAbortAction(true) and display an appropriate error message.

3. Client Scripts / UI Policies

• Hide or disable the attachment control based on the user's role or record state.
• This only improves the user experience and should not be relied on for security, since attachments can still be uploaded through APIs or other entry points.

4. Table-specific restrictions

• If attachments should only be restricted on specific tables (for example, Incident, Change, or Requested Item), implement the validation in an ACL or Business Rule by checking table_name and table_sys_id.

5. System Properties

• ServiceNow provides attachment-related system properties (such as maximum file size and allowed file extensions). These help control attachment behavior but do not provide user- or role-based upload restrictions.

Note: Data Policies are generally not used to restrict file uploads because attachments are stored in the sys_attachment table rather than being validated as record field data.

• ACLs are the preferred solution for enforcing security.
• Business Rules are useful for business-specific validation.
• Client Scripts/UI Policies should only be used to improve the user experience and should always be backed by server-side enforcement.

 

• Limit Access to Attachments Through ACL
• Restrict Access to Attachments on RITM (Community Discussion)
• https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0682392
• hhttps://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0718577 

 

[Vikram Reddy]

Hello @The Matrix,

This comes up in interviews a lot because ServiceNow doesn't have one single "block attachments" switch, it's a stack of controls and the interviewer is usually fishing for how many of them you know. Here's the layered set, from broadest to narrowest.

1. ACL on sys_attachment: this is the real enforcement point. Create a write ACL (and a create ACL if you want to be explicit) on sys_attachment with a role requirement or a script condition. In the script you have access to current, so you can check current.table_name to scope the rule to a specific table (e.g. only block on problem or a custom table) rather than instance wide.
2. glide.attachment.role system property: this is the global gate. It holds a comma separated list of roles allowed to create attachments anywhere on the instance. Leave it empty and everyone (including public/portal users) can attach; populate it and only those roles can.
3. glide.attachment.extensions and glide.attachment.blacklisted.extensions: these control what type of file, not who. The first is an allow list of extensions (doc,docx,xls,pdf,jpg etc.), the second is a deny list that only kicks in once glide.security.attachment_type.use_blacklist is true.
4. com.glide.attachment.max_size: caps file size in MB. Worth knowing an empty value here doesn't mean unlimited, it actually drops the effective limit to 1KB, which trips people up.
5. UI Policy or a client script to hide the paperclip/Attach UI action: this only removes the button from view. It is not security, a user can still POST to the attachment API directly, so it should never be your only control.

If this is for an interview, the answer they're really after is usually "ACL plus glide.attachment.role for who, extensions/blacklist properties for what, max_size for how big, and UI hiding is cosmetic only." If it's a real requirement, worth asking: are you trying to block by role, by table, or by file type/size? That changes which lever you reach for first.

Thank you,
Vikram Karety
Octigo Solutions INC

[Tanushree Maiti]

Hi @The Matrix 

1)Access Control Lists (ACLs)

• Write a create or write ACL on the sys_attachment table.
• Use script conditions in the ACL to block uploads for specific user roles or target tables

 Refer: https://www.youtube.com/watch?v=Zt4KynJanj0

2)Client Scripts 

• Refer: https://www.servicenow.com/community/itsm-forum/how-to-restrict-specific-file-names-in-attachment-va...
• KB0689021 How to prevent users from adding attachments to the record producers?   //Though DOM is not recommended

3) System Properties

• Inability to upload files with a .har extention to an Incident record
• https://www.servicenow.com/docs/r/platform-user-interface/restrict-file-extensions.html