GlideRecord update restricted by ACLs or Application Scope...?

[mattybrodriguez]

Recently we've been having issues relating to GlideRecord use in scripts.  We send out notifications to end-users who then reply to these with certain values, which we use to trigger related inbound actions, business rules, etc. in the system, often utilising GlideRecord to update cases, tasks and other records.  We've noticed that a lot of the time, users attempting to do this fail where admin users succeed - leading me to believe this is related to ACLs.  Has anything changed recently in regards to this?  I remember this was working at one point and is now causing us issues.  Additionally, does anyone know what I could do to bypass the ACLs using GlideRecord (without impersonating an admin user in the script)?

[Gaurav Bajaj]

Are you able to update the record from an end user manually?

[mattybrodriguez]

Not this type of user, as they are only able to interact with the system via email.  We do not intend to provide access for the user to interact with the back-end of SNOW

[matthewmaxwell]

Hi mattybrodriguezsanchez,

Do these users have a user record in sys_user?

The way that inbound actions work is that ServiceNow looks for an active user in the sys_user table that has an email address that matches the email address from which the email is coming. If the user is found, that user is impersonated. If that user record is not found, ServiceNow impersonates "guest". If multiple users have the same email address, the first user found is used.

If the users don't have accounts, that may explain why it's failing because GlideRecord updates would require a user to be logged in; however, GlideRecord updates on the server do not look at permissions. GlideRecordSecure does.

I would make sure the users have active accounts in sys_user.

See this for more information on inbound processing.

[mattybrodriguez]

Hey.  These users definitely exist in sys_user as I'm using test user accounts that I have created myself.

[matthewmaxwell]

You mentioned in the subject something about application scope.

I just created a test scoped application in my PDI and tried to insert a record into the table and it failed due to cross -scope access policies.

I was able to fix this by going into my scope application in studio, going to my table and setting the Can Insert and Can Update checkboxes to checked under the "Application Access" tab. See attached screenshot: