In Australia Release Q1 2026, New Columns have been added to Dictionary Table.
So, When I started Exploring after my successful upgrade to Australia Instance, I found this.
Let’s take an Example, I have open the Dictionary for the Category Field on the Incident Form as shown in fig.
The Previous Normal Read Only field is no longer available and Read Only Option is newly added.
Let’s walkthrough with my understanding from the Australia Release on this :
Read Only Option is Choice Type of Column, with options as usual stored in sys_choice as Display Read Only, Client Script Modifiable, Strict Read Only and Instance Configured. Although the Instance Configured is not made visible on the Incident Record which I have referred.
1) Instance Configured (Read-Only Option)
This option is mainly for older fields that were created before the Australia release. It helps ensure nothing breaks and everything continues to work as it used to.
When a field is set to Instance Configured, its read-only behavior is not fixed directly on the field. Instead, it depends on a system setting called glide.read_only.legacy_read_only_behavior.
By default, this setting allows client scripts to still modify read-only fields—just like in earlier versions.
So, in simple terms:
- It keeps the old behavior intact
- Useful for backward compatibility and testing
- Read-only fields can still be changed via client scripts (if allowed by the system setting)
2) Display Read Only (Read-Only Option)
This option makes the field appear as read-only on the screen, so users cannot edit it directly from the UI.
However, it doesn’t completely lock the field. The value can still be updated in the background using:
- Client scripts
- Server-side operations like APIs or scripts
In simple terms:
- Users can’t edit it manually on the form
- But the system can still update it programmatically
3) Client Script Modifiable (Read-Only Option)
This option makes the field read-only on the form, so users can’t edit it directly.
But it still allows changes through client scripts (like onChange or onLoad scripts running in the browser). At the same time, it blocks updates from server-side scripts or APIs.
In simple terms:
- Users can’t edit it manually
- Client scripts can update it
- Server-side scripts and APIs cannot change it
4) Strict Read Only (Read-Only Option)
This option completely locks the field.
It shows as read-only on the form, and no one can change it—not from the UI, not from client scripts, and not even from server-side scripts or APIs.
In simple terms:
- Users can’t edit it manually
- Client scripts can’t update it
- Server-side scripts and APIs also can’t change it
I can consider this Modern Data Policy Clone Copy here.
Now after this I have investigated more on this, then I found one OOB Client Script which has also been introduced to help user to understand the Read Only Behavior named as : Read Only Option warn message.
Basically, this Script is work as follow : “When the form loads, this script checks if the Read Only Option field is available and properly set, and shows helpful warnings if the behavior is controlled by system settings.”
- Warns if the field is missing
- Warns if the behavior depends on instance-level config
- Helps users understand what’s actually controlling read-only behavior
Now there is an interesting point : when we check the dictionary of any column, we can see that only 3 options are visible from the total 4. I have reviewed the dictionary table itself, as shown below.
So, Basically we cannot directly enable Instance Configured as 4th Choice.
This Option has been made Active = False in sys_choice table.
Reason which I thought is :
- It is not a standard selectable choice
- It is internally derived behavior, not meant for manual selection in UI
The OOB System Property glide.read_only.legacy_read_only_behavior controls the behavior.
Testing Read-Only Behavior :
The Instance Configured option is mainly there to support older fields and avoid breaking existing functionality after the Australia release.
It also gives you a safe way to test different read-only behaviors before applying them in production.
When a field is set to Instance Configured, its behavior depends on a system property called glide.read_only.legacy_read_only_behavior.
By default, this property is set to client_script_modifiable, which means:
- The field looks read-only on the form
- But it can still be updated using client scripts
For testing in non-production (like dev or test instances), you can change this property to try different behaviors:
- display_read_only → UI is read-only, but scripts/APIs can update
- client_script_modifiable → Only client scripts can update
- strict_read_only → No updates allowed from anywhere
This helps you understand how your fields and scripts will behave before making changes in production.
Important:
This system property is only meant for testing.
If you change it, it will impact all fields that are set to Instance Configured, so it should not be used in production.
Example: Testing Strict Read Only
Let’s say you want to check how stricter read-only rules will impact your existing scripts and customizations.
In a non-production instance (like dev or test), you can set the system property glide.read_only.legacy_read_only_behavior to strict_read_only.
This will temporarily make all fields (set as Instance Configured) behave as fully read-only.
Once you do this, you can test your forms, client scripts, and integrations to see if anything breaks or needs changes.
After you’re confident everything works fine, you don’t need to change the system property in production.
Instead, you can go field by field and set only the required fields to Strict Read Only.
In simple terms:
- Test strict behavior safely in non-production
- Validate your scripts and customizations
- Then apply it carefully in production, only where needed
Please Find Official ServiceNow Documentation Link Below. The Above Explanation is my own Explore on this Functionality.
