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)?

[mattybrodriguez]

Just checked and the two main tables I'm trying to affect (csm_order_case and sn_customerservice_task) have been setup like above

[matthewmaxwell]

Are you able to provide any example implementation code? How can I set a test user up in the same way you've got them set up?

[matthewmaxwell]

For what it's worth, canCreate and canWrite on the GlideRecord instance will tell you if ACLs are the issue but as far as I know, GlideRecord does not look at ACLs because GlideRecordSecure does that.

[matthewmaxwell]

Also just thought of this: Are there any before update business rules that might be messing up your update?