Strict Read Only field can still be updated via GlideRecord

[Rin Kaneko]

Hi Community,

I am testing the new Read only option on sys_dictionary in a Personal Developer Instance (PDI).

According to the official documentation, setting a field to Strict Read Only is expected to prevent any updates from UI, Client Scripts, and Server-side APIs.

However, during my verification on a PDI, I observed that the field value could still be updated via server-side execution. Here are the test details:

[Test Configuration]

Table: custom table

Field: custom field

Read only option: Strict Read Only

[Test Results]

Background Script: Executed GlideRecord.update() without using setWorkflow(false). The field value was updated successfully.

Business Rule (before update): Set current.setValue() The field value was updated successfully.

[Question]

Does Strict Read Only only enforce restrictions on the Client/UI layer (e.g., REST API / g_form / Form submission), while bypassing GlideRecord database updates in server-side scripts regardless of user roles? Or is this an unexpected behavior/defect in the current release?

Any insights or official behavior clarifications would be greatly appreciated.

[Hemanth M]

Hi @Rin Kaneko ,

I think document should have given more clarity around GlideRecord update (they bypass ACLs) , i don't think you can update using GlideRecordSecure.

[LhoraMaeA]

Hi @Rin Kaneko 

I have the same question as you.

Were you able to resolve it?

Do you have any insights you can share?

[sonalibhaga]

The key distinction appears to be plain GlideRecord versus security-aware server APIs.

 Strict Read Only configured, is followed by successful updates from GlideRecord.update() and current.setValue() in a Business Rule. The reply points out that ordinary GlideRecord operations can bypass ACL/security enforcement . Try testing with GlideRecordSecure.

Accept and hit Helpful if it helps.

Thank you,