ServiceNow Australia Release
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
15 hours ago
BLOG : Australia Release - The End of "Suggestive" Data Integrity – New Read-Only Dictionary Attribute
For years, ServiceNow developers and architects have operated under a known limitation: the "Read-only" checkbox in the Dictionary was often more of a suggestion than a rule. While it effectively locked fields on the UI for average users, it could be easily bypassed by client scripts, browser consoles, and server-side APIs.
With the Australia release, ServiceNow has introduced a fundamental shift in how we handle data integrity. The simple "Read-only" checkbox is gone, replaced by a sophisticated Read-only Option dropdown that provides true enforcement at the platform level.
The Problem with the Legacy "Read-only" Checkbox
In versions prior to Australia (such as Zurich), setting a field to read-only only prevented manual user input. However:
Client Side: A developer could use g_form.setValue() or the browser console to modify the field and save the form.
Server Side: APIs like GlideRecordSecure, Table API could still bypass these restrictions, leading to data inconsistencies and security gaps.
Introducing the New Read-only Options
In the Australia release, the Dictionary entry now features three distinct enforcement levels:
1. Display Read Only
This mimics the legacy behavior.
Behavior: The field is read-only on the UI.
Modifiable by: Client scripts, browser consoles, and server-side operations (Table API and GlideRecordSecure).
Best use: When you want to prevent user errors but still allow programmatic updates.
2. Client Script Modifiable
This adds a layer of server-side protection while keeping UI flexibility.
Behavior: The field is read-only for users but can be updated via g_form.setValue().
Blocked: Server-side APIs using GlideRecordSecure, Table API, or GraphQL cannot modify the field.
Note: Standard GlideRecord (which ignores ACLs) can still bypass this, as it does not respect the security layer.
3. Strict Read Only
This is the ultimate enforcement level for maximum data integrity.
Behavior: The field is strictly locked.
Blocked: Neither client scripts nor server-side APIs (GlideRecordSecure, etc.) can change the value.
Feedback: ServiceNow provides clear logging, such as: "Ignored call to setValue of strict read-only field" .
Critical Impact on Build Partners and Custom Apps
If you are a ServiceNow Build Partner or manage custom scoped applications, this change is urgent:
Upgrade Impact: Upon upgrading to Australia, background scripts, fix scripts, and scheduled jobs using GlideRecordSecure will stop working for restricted fields.
Deadline: ServiceNow is already communicating with partners to recertify applications. In some cases, updates and recertification are required as early as April 30th.
Global Property: There is a new system property (glide.ui.dictionary.readonly_option_default) that defaults to "Client Script Modifiable" to prevent immediate breakage of existing UI logic.
Final Thoughts
The Australia release brings a much-needed "complete overhaul" to field security. By moving away from "suggestive" read-only fields to strict platform-level enforcement, ServiceNow is giving architects the tools they need to ensure data remains consistent and secure across all entry points.
