- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-13-2025 05:38 AM
Our instance overnight has suddenly gained 16,000+ acl's all with the updated by as "@@snc_write_audit@@"
Any ideas what might of caused this or how we can reverse it?
Solved! Go to Solution.
- 6,278 Views
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-13-2025 06:04 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-14-2025 07:13 AM
Same thing is happening with us now.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-13-2025 11:42 AM
@@snc_write_audit@@ :- This value is not a user.
It’s a special internal system marker used by ServiceNow during certain types of silent data updates, especially when:
- The platform does not want to assign a human user to the update
- An update is made outside of GlideSession context
- A mass update, fix script, or system-level ACL sync occurs
Please open a ticket to servicenow and ask for more clarification.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-14-2025 01:49 PM
We found this problem today on a custom app/table one field, it was missing the new ACL for that field, hundreds of other ACLs added by this update were in place.
User had direct access via role created for the fulfilment team but the query search was failing, direct search (non asterisk as an example or choose 'is' instead of "contains" worked.
We added a new ACL for the field that was failing on searches and this now restored their ability to use the contains or asterisk search options.
We will have to keep an eye for other fields this update missed, very odd that is put ACLs in place for most of our u_ created fields but missed this one.
