GlideRecordSecure cannot update HTML field on custom table, but GlideRecord works

[Ganesh Prasad C]

Hi Community,

We are trying to update an HTML field on a custom table using a script include.

When we use GlideRecord, the update works as expected.
However, when we switch to GlideRecordSecure, the update does not work.

What we have already checked/tried:

• Verified ACLs (read/write) on the table and the HTML field

• Ensured the integration user has the required roles

• Added the integration user to the Conditional Script Writer group

• Verified custom application cross-scope privileges

Despite this, the update only works with GlideRecord and fails with GlideRecordSecure.

This behavior started after our instance was upgraded to the Zurich release. Prior to the upgrade, the same logic was working as expected.

Any guidance would be appreciated.

Thanks in advance!

[Tejas Adhalrao]

Hi @Ganesh Prasad C  ,

• GlideRecord → ignores security → update works

• GlideRecordSecure → follows security → update does NOT work

GlideRecord  -> don't check any ACL and directly update

GlideRecordSecure  -> checks field security (ACLs) very strictly

Use GlideRecord for:  Integrations , Backend scripts

After the Zurich upgrade, GlideRecordSecure enforces field-level ACLs much more strictly., This causes updates to fail even when roles, groups, and cross-scope privileges are correctly configured. GlideRecord bypasses these checks, which is why it still works. This is expected behavior in Zurich. For integrations or trusted backend logic, using GlideRecord is the recommended and supported approach

[Aditya_hublikar]

Hello @Ganesh Prasad C ,

Im also not sure why in zurich instance this difficulty is getting faced , i read some articles so got following information , may this helps you .

After the Zurich upgrade, ServiceNow introduced stricter security enforcement for GlideRecordSecure, especially when updating HTML fields. This is why the same logic that worked earlier now succeeds with GlideRecord but fails with GlideRecordSecure.

The key difference is that GlideRecord bypasses ACLs, while GlideRecordSecure strictly enforces both table-level and field-level ACLs. From Zurich onward, this enforcement is much tighter.

For HTML fields, this change is more noticeable because they are treated as high-risk fields due to the possibility of script injection.

Below are the most common reasons this happens even when ACLs look correct:

1)The field-level Write ACL for the HTML field does not explicitly allow scripted updates. Older ACLs that worked before Zurich may no longer be sufficient.

2)The ACL script includes checks like gs.isInteractive() or UI-only logic, which will fail for Script Includes and integrations.

- Cross-scope restrictions are now enforced more strictly. If the Script Include and the table are in different application scopes, the correct cross-scope privileges must exist

- HTML sanitization may silently block the update if the content contains restricted tags or scripts. In such cases, update() fails without throwing an error.

To confirm the issue, you can test the update as the integration user using GlideRecordSecure and check whether canWrite() returns true. If it does not, the problem is ACL-related. If it returns true but the update still fails, HTML sanitization or field-level ACL logic is likely the cause.

Recommended approaches:

- Best practice: Continue using GlideRecordSecure, but update the HTML field Write ACL to explicitly allow scripted access and remove any interactive-only checks.

- Integration-only workaround: If this is a trusted backend integration and security is already handled elsewhere, using GlideRecord is acceptable since it bypasses ACLs

- Alternative design: Store the content in a normal string field and render it as HTML at display time to avoid strict HTML write enforcement.

[Aditya_hublikar]

Hello @Ganesh Prasad C ,

Does my response helps you ? If yes then you can mark it as helpful and accept as solution, so it will helps in future for further queries.

Regards,

Aditya

[Ganesh Prasad C]

Hello @Aditya_hublikar, 

For the query below, we’ve already verified the ACLs related to the HTML field. The canWrite() check is also returning true for the integration user. Based on this, do you have any suggestions or see a better way to handle this?

Regards, 
Ganesh