What is the *.sys_id write ACL there for?

[mmmgawa]

I was having an issue where we were using REST API calls to create records in a table and we were getting a 201 and the record was created but the response body was empty.

I came across this KB: ServiceNow KB: POST method of REST web service inserts a record but does not generate a response (KB...

Sure enough the OOB write ACL for *.sys_id was active and when I deactivated it I started to get a response body.

Problem solved right? Well I can't figure out why it was activated and I also can't seem to wrap my head around why this ACL is even a thing if it is supposed to not be active OOB?

I guess the real question is what reason would an organization have to activate this and why would it be active in my environment? I guess if someone wanted to write records including the sys_id so that it would match some other system but I would think that a table level or a "table.*" write ACL would cover the sys_id as well yes? Outside of the KB that I found I can't seem to find anything else that discusses this ACL and what it does.

[adilrathore]

It is disabled by default, though there is no documentation on why it does exist.

[shruti_tyagi]

Hi Scott,

This ACL is deactivated in OOB instance, not sure how was it activated in your instance. Which build you are in?

Shruti

[mmmgawa · Accepted solution]

It looks like I goofed a bit and missed that there is a script in there that is set to 'false'. This means that when this ACL is enabled it will not allow anyone to set a sys_id except an admin. It was enabled on our end as an effort to harden the system from wrongdoing and this can explain it's existence but there are some strange things that can result from when it is enabled. For example some create records calls can return a 201 but an empty response.

Thanks,

Scott