Edit Read Only Fields Permission in Salesforce: What It Unlocks

Yes. Salesforce has a system permission called Edit Read Only Fields. It lets a user edit fields that are marked Read-Only on a page layout. It is on by default for the System Administrator profile, which is why admins can often edit a field their users cannot.

It is also narrower than the name suggests. A field can be read-only for five different reasons, and the permission only covers one of them.

What Edit Read Only Fields does

When an admin marks a field Read-Only in the page layout editor, users on that layout see the field but cannot change it. A user with Edit Read Only Fields can.

That is the whole effect. It is a UI-level override for a UI-level setting.

To give it to someone other than an admin, create a permission set, open System Permissions, enable Edit Read Only Fields and assign the permission set. Granting it through a permission set rather than a profile keeps a clear list of who holds it. Hand it out sparingly. The layout said read-only for a reason, and this permission applies to every layout-read-only field on every object the user can edit.

What it does not override

Why the field is read-only	Does Edit Read Only Fields help?	The fix
Marked Read-Only on the page layout	Yes	Grant the permission, or give the user a layout where the field is editable
Field-level security gives Read but not Edit	No	Grant Edit on the field in a permission set
Formula, roll-up summary or auto-number field	No	Not editable by anyone. Add a separate editable field
Audit fields (CreatedDate, CreatedById)	No	Set Audit Fields upon Record Creation, at insert only
Validation rule, flow or trigger blocks the change	No	Change the automation or add a bypass for the right users
Locked by a managed package or an approval lock	No	Depends on the package, or unlock the record

Field-level security: the most common cause

If the field is read-only for every user on a profile, regardless of layout, check field-level security first. In Setup, open the field and click Set Field-Level Security, or look at the field permissions in the user's profile and permission sets. A field with Read access but no Edit access is read-only in the UI, in the API and in user-mode Apex.

The fix is a permission set that grants Edit on that field, assigned to the users who need it. No system permission gets around field-level security, including Modify All Data.

Calculated fields: formula, roll-up summary, auto-number

These fields are computed by Salesforce, so nobody can write to them. When users need to override a calculated value, the usual pattern is:

1. Add an editable field, for example Discount_Override__c.
2. Change the formula so it uses the override when one is entered: IF(ISBLANK(Discount_Override__c), <original logic>, Discount_Override__c).

Audit fields during a data migration

CreatedDate, CreatedById, LastModifiedDate and LastModifiedById are read-only in normal use. During a migration you often need to keep the dates from the old system. To do that:

1. In Setup, open User Interface and enable "Set Audit Fields upon Record Creation" and "Update Records with Inactive Owners" User Permissions.
2. Assign the Set Audit Fields upon Record Creation permission to the integration or migration user, ideally through a permission set.
3. Include the audit fields in the insert through Data Loader or the API.

This works on insert only. Once a record exists, its audit fields cannot be changed.

Layout read-only does not apply to the API

A layout only controls the record page. If a field is read-only on the layout but field-level security allows Edit, the field can still be updated through the REST, SOAP or Bulk API, Data Loader, Apex and flows. For example:

PATCH /services/data/v62.0/sobjects/Account/001XXXXXXXXXXXXXXX
Content-Type: application/json

{ "Custom_Field__c": "New value" }

That is worth remembering in both directions. A layout is not a security control. If a field must not change, protect it with field-level security or a validation rule, not with a read-only layout setting.

Quick checklist

1. Same result for every user on the profile? Check field-level security.
2. Editable for admins but not for users? It is probably layout read-only. Grant Edit Read Only Fields or change the layout.
3. Formula, roll-up or auto-number? Not editable. Add an override field.
4. Audit field? Only during insert, with Set Audit Fields upon Record Creation.
5. Edit saves but the value changes back or errors? Look at validation rules, flows and triggers on the object.