Read-only rules

Lock a field from editing. Six sources of read-only state, OR'd together, and the two different ways the runtime renders the result.

A read-only field shows its value but cannot be edited. Six separate things can put a field in that state, and the runtime takes the OR of all of them: if any source says read-only, the field is read-only.

The six sources

They are listed in the order the runtime checks them. The order matters, because the winning source decides how the field is rendered (see the next section).

PropertyDescription
Display form
form mode
A form opened in Display mode is entirely read-only. Nothing on the field can override this.
SharePoint server-side
inherited
Three cases: the column carries SP’s own ReadOnlyField flag; its internal name is system-managed (Created, Modified, Author, Editor, ID, GUID, ContentTypeId, or anything starting with _); or its column type is inherently computed (Calculated, Computed, Counter, Guid, ModStat, WorkflowStatus, WorkflowEventType). None of these can be made writable from the form.
readOnly
boolean
Static author flag, set once in the designer. The per-field display mode fieldDisplayMode: "view" is an alias for it, so setting either locks the field.
readOnlyOnNew
boolean
Read-only while the form is in new mode. Useful for a field that only becomes meaningful after the item exists.
readOnlyOnEdit
boolean
Read-only while the form is in edit mode. Useful for a value that must be set once at creation and never changed (a request reference, an order number).
enableIf
expression
The conditional source: while the expression is false the field is locked, and it unlocks the moment the expression turns true. See the enableIf reference.
enableForGroups / disableForGroups
string[] (group names)
Audience trimming: editable only for members of the listed Entra or SharePoint groups, or locked for them. See the audience reference.

Two ways it renders

Which source won decides what the user sees. This is deliberate: a rule that can flip back should leave the control in place, while a permanent lock should not pretend to be an input.

PropertyDescription
enableIf is the only reasonThe real control stays in the DOM, rendered disabled (greyed). It becomes fully editable again the instant the expression turns true, without remounting, so a value set by JavaScript or by a picker survives the flip.
Any other sourceThe control is replaced by a read-only value display, the same renderer Display form uses, so formatting is consistent no matter which source caused the lock. A small lock glyph is shown, except on Display form (where everything is locked, so the glyph is noise) and on calculated fields (which are computed, not locked).

A read-only field still saves its value

In both treatments the field contributes its value to the save, through a hidden input rendered alongside it. That matters more than it sounds: a disabled control is omitted from the browser's form data, and a value display is not an input at all, so without the hidden carrier a locked field would write null over its own column. With it, an author's default on a locked field lands on create, and a loaded value is rewritten unchanged on edit.

This includes complex values. A locked or hidden lookup, person or managed metadata field carries what its picker would have sent: the lookup IDs, the people, or each term's label and ID. So a locked Managed Metadata field keeps its terms on save instead of being cleared.

One limit worth knowing:

  • Server-managed columns are dropped from the payload later anyway, by the read-only strip pass in the submit pipeline. SharePoint would reject them.

Related articles