I want to remove attachment control for records that have read-only control set in the ACL.

[bonsai]

There are records set to read-only in the ACL.

We want to allow users to delete and add attachments to these read-only records, although field operations are not possible.

Is this possible?

The requirement is that when a requester views a read-only record, they should only be able to add and delete attachments.

Since the requester is a read-only user, we are unsure whether we should grant them record editing permissions.

[Yogesh11bhatt]

Hi @bonsai ,

Yes, this is possible, and you do not necessarily need to grant write access to the parent record.

This requirement is achieved by separating record-level security from attachment-level security.

How Attachment Security Works

Attachments are stored in the sys_attachment table (with content stored in sys_attachment_doc).

When users interact with attachments, ServiceNow evaluates attachment-related ACLs as well as the access model associated with the parent record. Because of this, attachment access can be configured independently, but it should be tested carefully against your existing ACL structure.

Recommended Approach

Keep the parent record read-only and implement attachment-specific access controls.

1. Review existing ACLs on:

   • sys_attachment

   • sys_attachment_doc

2. Create or modify ACLs as needed for:

   • Read (view attachments)

   • Create (upload attachments)

   • Delete (remove attachments)

3. Restrict those ACLs to:

   • The appropriate requester role(s)

   • The specific table(s) involved

   • Any business conditions required by your process

Important Consideration

Avoid granting record write access simply to support attachment uploads.

A cleaner design is:

• Record fields remain read-only.

• Users can still add/delete attachments through attachment-specific ACLs.

• Existing governance around record updates remains intact.

Testing Recommendation

After configuring the ACLs:

• Impersonate a requester.

• Verify the record remains read-only.

• Verify the paperclip/upload control is available.

• Verify attachment deletion behaves as expected.

• Confirm no unintended access is granted on other tables.

If attachment operations are still blocked, review any custom ACLs, UI Policies, or attachment security logic already present in your instance, as these can influence the final behavior.

Hope this helps!

Please mark this answer as Helpful if it resolves your question. 🙂

Thanks,
Yogesh Bhatt

[bonsai]

The attached file is retrieved from a catalog item within the flow and moved, so the creator is "system".

Would the above settings still work even with this added condition?