Read-Only Is A Choice Field Now

If you certified an app on Zurich and are taking it to Australia, your read-only fields have already changed behaviour. And nothing has broken to tell you.

Every field created before Australia defaults to Instance Configured, whose behaviour resolves from a property on the customer’s instance. So the same certified app can protect data differently for different customers. Certification review raised this on each app we’ve forward-migrated from Zurich so far.

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. That 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.

In our testing on Australia instances, a further property, glide.ui.dictionary.readonly_option_default, sets the default for newly created read-only fields. On those instances it defaults to Client Script Modifiable so existing UI logic keeps working. That 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. 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. That happens when one of them changes 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.

Did the old read-only checkbox ever stop a write?

No, and that 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(). You may have used read-only as a data-integrity control—to stop a total being edited, an audit field being overwritten, an integration key being changed. If so, 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.

What does certification review raise about read-only fields?

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. The instruction was to 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 (a script that runs once, on install or upgrade) 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. ServiceNow’s Run fix scripts page says “previous fix scripts do not run on subsequent application updates, and you must manually run any necessary fix scripts.”

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 this. 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. It should do that 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. So it should guard its own writes rather than assume a single clean pass.

What should I check before recertifying on Australia?

ServiceNow’s Australia early-release post says: “Partners are expected to submit their application for certification or recertification on the Australia release once the Australia opens.” 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 on Australia and later. 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. On Zurich the option doesn't exist yet, so use one of the two routes above.
4. Retest anything that writes those fields. In our testing on Australia instances, Strict Read Only silently refuses writes and 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.

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

On the deadline behind all this: the n-3 rule, and the 158 partner apps our study found one release from falling outside it.

Questions

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

Partly. Existing fields resolve to Instance Configured after the upgrade, so forms can look unchanged. Don't take that as proof that nothing changed. Test any integration or background job that writes to read-only fields through the Table API or server-side scripts. Do that testing on an upgraded instance before you rely on the integration or job.

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. 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. Each app we’ve taken from Zurich certification through to Australia certification so far has had this raised in review. 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?

Not necessarily. ServiceNow suggested two, 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. The Australia read-only options never get applied when that instance later upgrades. An admin has to run the script manually post-upgrade, so document it where they will look.