Is there any special permission available to edit read-only fields? Please explain

Short answer

No one permission unlocks every read-only field in Salesforce. Whether you can edit a field depends on which of 6 causes is behind it, from a page layout setting or Field-Level Security up to formula and auto-number types that stay calculated no matter who is asking. Where the cause allows it, you open up editing by changing profile permissions, updating the page layout, writing through the API, or assigning the Set Audit Fields permission.

Why a field is read-only (and what that means)

Work out the cause first, because the fix is different for each one:

• Field type. Formula, roll-up summary, auto-number and other calculated or system fields are never editable.
• Field-Level Security (FLS). If a profile or permission set marks the field read-only, the user cannot change it, and neither can API calls made as that user.
• Page layout read-only. A field marked read-only on the layout is still editable through the API when FLS permits it. The layout setting only affects the UI.
• Validation rules, triggers, process builders and flows. Business logic can block an edit or revert it.
• Managed package or namespace protection. Some fields in managed packages are protected and cannot be edited.
• System audit fields. CreatedDate, CreatedById and LastModifiedDate are read-only under normal conditions, with the exception below.

Special permissions & features

The exceptions worth knowing:

• Set Audit Fields upon Record Creation

  This feature, also called "Create Audit Fields", has to be turned on for your org, and the user needs the matching permission. It lets you set audit fields such as CreatedDate, CreatedById, LastModifiedDate and LastModifiedById while a record is created through the API or the data loader. It applies at creation time only, not to arbitrary later edits, and older orgs need Salesforce Support to enable the feature at the org level. This is what you use for data migration and backfills.

• Modify All Data / Customize Application

  These broad administrative permissions let an administrator change security settings, updating FLS or a page layout so fields become editable for certain users. They do not reach through to immutable field types such as formula and auto-number, or to protected managed-package fields.

• Permission Sets / Profile FLS

  Granting Edit through FLS on a profile or permission set is the standard way to make a previously read-only field editable. It is the normal access control mechanism doing its job.

• API vs UI differences

  A field set read-only on a page layout can still be updated through the API, whether SOAP, REST or Bulk, when FLS allows the edit. When FLS itself marks the field read-only, the API update fails too. The API is no way around FLS and security restrictions.

What you cannot do (even with high-level permissions)

Some limits no admin flag reaches:

• Modify formula, roll-up summary and auto-number fields. These are system-controlled and calculated.
• Edit fields a managed package provider has protected, unless the package exposes an interface for it.
• Change audit fields after creation, outside the data migration case where "Set Audit Fields" applies at creation time.

Practical steps to allow editing

If you need to edit a read-only field:

1. Work out why it is read-only: field type, FLS, page layout, managed package or business logic.
2. For FLS, update the profile or build a permission set with Edit access and assign it to the user.
3. For a field that is read-only on the layout but editable under FLS, use the API, or give the user a different page layout so they can edit in the UI.
4. For audit fields during a migration, request "Set Audit Fields upon Record Creation" and populate the values at insert time with the API or Data Loader.
5. For a formula, auto-number or roll-up field, create a separate editable custom field and populate it through data migration, or through automation where that fits.

Example: updating an editable-but-layout-read-only field via REST API

When FLS allows the edit and only the layout is read-only, go through the API. A REST example, with your own instance URL and session token:

PATCH /services/data/vXX.X/sobjects/Account/001XXXXXXXXXXXXXXX { "Custom_Field__c": "New value" }

If the field is read-only because of FLS, this call comes back with an insufficient access error.

Summary

No one special permission overrides every kind of read-only field. What you can do follows from why the field is locked. Use permission sets and FLS to grant edit access, ask Salesforce to enable "Set Audit Fields upon Record Creation" for migrations, and take true system fields and calculated fields as uneditable.