What is the role behind "system" user?

[Vishnu kumar R]

I have tried using Scheduled script with "Run As" as empty and I can see on executing script, All the related records are getting updated with the name as "system", Now I need to know will that "system" user is accessible to all records and all tables?

I have tried restriction using ACL record creation to all users, But on executing scheduled script I can able to still see records are getting created with created user as 'system'.

Question:

Will "Run As" user follows ACL restriction when empty?

Do we need to add required role to the user that we are adding to "Run As" user?

Thanks,

Vishnu Kumar R

[iekosmadakis]

Hello @Vishnu kumar R !

If "Run As" is left empty, the scheduled script runs as the system user. The system user in ServiceNow is a special, internal account used for background processes. It bypasses all ACLs, meaning ACL restrictions you configure for regular users do not apply to it. This is why even if you restrict ACL creation to all other users, the scheduled job still creates/updates records.

If you want ACL rules to apply, set "Run As"  to a real user (not empty). The script will then execute in that user’s security context, meaning ACLs will apply. In that case, yes, you must ensure the "Run As" user has all required roles to perform the script’s actions; otherwise, the script will fail where ACL denies access.

Please consider marking my answer as helpful and accepting it as the solution if it assisted you in any way.

[Rafael Batistot]

hi @Vishnu kumar R 

Question 1: 

Yes, and no. This is where the distinction is crucial.
When the "Run As" field is empty on a Scheduled Script Execution, the job runs as the "System" user. The "System" user is not a regular user in the sys_user table. It's a special, internal account that operates with a high level of privilege.

Question 2:

Yes, absolutely.
This is the key to running your scheduled script with specific permissions and adhering to security best practices.
* When you specify a user in the "Run As" field, the scheduled script runs with the exact same permissions as that user. This means it will be bound by all ACLs, roles, and user-specific restrictions that apply to that user.
* If the user in the "Run As" field does not have the necessary roles to perform an action (e.g., create, read, update, or delete a record on a specific table), the script will fail to perform that action.

[Ankur Bawiskar]

@Vishnu kumar R 

if you are inserting Record using GlideRecord then ACLs won't be evaluated.

if you use GlideRecordSecure then ACLs come into picture.

It's recommended to run scheduled job using "System" user as that's the highest level of user in instance.

If my response helped please mark it correct and close the thread so that it benefits future readers.

[Vishnu kumar R]

Hello @Ankur Bawiskar , @Rafael Batistot , @iekosmadakis ,

Thanks for your valuable answers!

@Ankur Bawiskar I have tried with GlideRecordSecure() it is checking backend ACL.

I have tried with tagging user with no role as "Run As" and tested scheduled import and scheduled script and I can still see record is getting created!

And the interesting part is I have tried making that user Inactive and I can still see records Created, Updated!

So, Is "Run As" user is just for tracking purpose?