Read-Only Is A Choice Field Now

What actually changed in Australia?

The dictionary's read-only checkbox is gone. In its place is a choice field named Read only option, with four values stored in sys_choice. The change matters because the old checkbox controlled the form only—it never stopped a script from writing the field. The new options do, if you pick the one that does.

ServiceNow documents the field itself under Read-only options. What the docs do not cover is what this means for an app you ship to other people's instances, which is the rest of this page.

What does each read-only option block?

The four options differ only in who can still write the field. The UI is read-only in all of them.

There is also a property, glide.ui.dictionary.readonly_option_default, that sets the default for newly created read-only fields. It ships defaulting to Client Script Modifiable so existing UI logic keeps working, which is sensible for a platform upgrade and misleading if you assume new fields are strict.

Why is Instance Configured a risk for a Store app?

Because it moves the decision out of your app and onto the customer. Instance Configured is the default for every read-only field created before Australia, and its behaviour is resolved from glide.read_only.legacy_read_only_behavior—a system property on whichever instance the app is installed. The property ships set to client_script_modifiable.

For an app distributed through the Store, that is a portability problem rather than a configuration detail. Two customers running the same certified version of your app can get different enforcement, because one of them changed a platform property you have no visibility into. Anything you documented as protected is only protected on instances that happen to agree with you.

This is not hypothetical for existing apps. If your app predates Australia and you have not touched its dictionary entries, every read-only field in it is currently in this state.

Read-only was never enforcement—and that is the real finding

Worth saying plainly, because it changes what you should check: the old read-only checkbox was display read-only. Client scripts could write the field. So could the Table API, GraphQL, and GlideRecordSecure(). If you ever used read-only as a data-integrity control—to stop a total being edited, an audit field being overwritten, an integration key being changed—you were relying on protection that did not exist.

Australia is the first release where you can actually enforce it. That is the upside. The catch is that you have to choose it: nothing about the upgrade converts a display-only field into a strict one, and the defaults are deliberately set to preserve old behaviour.

What certification review actually raised

It came up as a forward-migration issue, not a feature question. Taking a Zurich-certified app through to Australia certification, the review raised the dictionary change directly: go through the app's dictionary entries and correct the read-only choice where it needs correcting. That is the shape of the conversation to expect—not "did you use the new field", but "have you reviewed what your existing fields now resolve to".

The reason it is a migration problem rather than a build problem is that the choice values do not exist before Australia. You cannot set Strict Read Only on a Zurich instance, because there is nothing to set it on. So an app that has to install on both releases cannot simply declare the right value and be done.

How do you ship one app across Zurich and Australia?

There are two ways through this, and the trade-off is real enough that it is worth stating both.

Two app versions—a pre-Australia build and an Australia build—is the approach ServiceNow suggested to us. It is clean: each version declares exactly what its platform supports, and nothing has to detect anything at runtime. The cost is that you now maintain, test and certify two lines of the same app for as long as customers sit on both releases.

One version plus a fix script is what we did instead. The script checks the platform version and applies the Australia read-only options only where the choice field exists, so a single certified app installs correctly on either release.

That choice has a sharp edge, and it is the thing to plan for rather than discover: a fix script runs once per instance. If a customer installed or updated the app while still on a pre-Australia release, the script has already run and will not run again. When that customer later upgrades to Australia, the read-only options are not applied—and a ServiceNow admin has to run the script manually after the upgrade.

So the honest comparison is: two versions moves the burden onto you permanently, one version plus a script moves a smaller burden onto the customer in one specific sequence. If you take the second route, that sequence belongs in your install and upgrade documentation, not in your own head—it is the part an admin cannot guess.

Two things make that route safer. Running the script is not the hard part—knowing it is needed is. An admin can invoke a fix script from System Definition whenever they like, so the gap to close is detection, not invocation: have the app surface its own state, by checking whether the read-only choice exists on the platform while your dictionary entries are still on Instance Configured. And write the script to survive being run twice. Precisely because a human can trigger it by hand, it will eventually be run on an instance where it has already applied, by someone who was not sure—so it should guard its own writes rather than assume a single clean pass.

What should I check before recertifying on Australia?

Partners are expected to submit for certification or recertification on Australia once it opens, and dictionary entries ship inside the app—so this is the natural moment to audit read-only options rather than discover them later.

1. Inventory the read-only fields your app ships. Query sys_dictionary within your application scope and list every entry with a read-only option set. Instance Configured is the value to look for.
2. Decide the intent for each one, field by field. If the field exists to be tidy on a form, Display Read Only or Client Script Modifiable is honest. If the value is a fact your app depends on, it should be Strict Read Only.
3. Set it explicitly. Do not ship Instance Configured. Leaving it transitional exports the decision to the customer's property and makes your app's behaviour untestable from your side.
4. Retest anything that writes those fields. Strict Read Only will silently refuse writes and log them—ServiceNow logs a message about ignoring a setValue call on a strict read-only field. A background job or integration that quietly stopped working is the failure mode to look for.
5. Test both install paths. ServiceNow's guidance for the Australia early-release programme is to test an upgraded vendor instance with your app already installed and a clean install onto a freshly zbooted Australia instance, because both are real customer situations.

Questions

Does the old read-only checkbox still work after upgrading?

Existing fields keep working, because they resolve to Instance Configured and the governing property defaults to the legacy behaviour. Nothing breaks on upgrade. That is exactly why it is easy to miss—the absence of breakage is not evidence that your fields are protected.

Which option should a Store app use?

Whichever matches the field's purpose—but explicitly, not Instance Configured. Strict Read Only for values your app treats as facts; the lighter options where automation is meant to write. The point is that the choice lives in your app rather than in a customer's property.

Will Strict Read Only break my integrations?

It can, and that is the reason to test rather than set it everywhere. Strict Read Only blocks server-side writes too, so an inbound integration or scheduled job that populates the field will stop—quietly, with a log entry rather than an error surfaced to a user.

Does certification review actually check this?

In our experience, yes. Every app we took from Zurich certification through to Australia certification had this raised in review, with a direct instruction to go through the dictionary entries and correct the read-only choice where needed. We are describing what review asked of us rather than quoting a published criterion—but if you are forward-migrating an app, plan on having an answer ready.

Do I need two versions of my app?

ServiceNow suggested exactly that: a pre-Australia build and an Australia build, since the choice values do not exist on the older release. It is the cleaner engineering answer and the more expensive one to maintain. A single version with a version-detecting fix script also certifies, at the cost of the run-once problem described above.

What happens if the fix script already ran before the customer upgraded?

Nothing, and that is the problem—a fix script runs once per instance. An app installed or updated on a pre-Australia release has already consumed its run, so the Australia read-only options never get applied when that instance later upgrades. An admin has to run the script manually post-upgrade, which means it has to be written down somewhere they will look.

Part of our ServiceNow app certification guide — what the review checks, the real timeline, and what apps fail on.