Read Only
Read Only is a Salesforce access level that lets a user view data without being able to edit, create, or delete it.
Definition
Read Only is a Salesforce access level that lets a user view data without being able to edit, create, or delete it. It can apply to a single field, to whole records of an object, or to a record-detail page, depending on which control sets it.
Read Only is not one feature. It is the result you get from several different security tools: field-level security, page layouts, object permissions, and organization-wide sharing defaults. Each one produces a read-only outcome in its own scope, and Salesforce combines them so the most restrictive applicable setting wins.
Where Read Only comes from in Salesforce security
Read Only at the field level (field-level security)
The most common source of read-only access is field-level security, also called field permissions. Each field on an object carries two checkboxes per profile or permission set: Read and Edit. When you grant Read but not Edit, the field becomes read-only for that user. They can see its value on the record page, in list views, reports, and search results, but they cannot change it. If you clear Read as well, the field is hidden entirely rather than read-only. Field-level security is enforced everywhere, not just on the page. Salesforce says it controls visibility in any part of the app, including related lists, list views, reports, and search results. That makes it the preferred way to protect sensitive values such as salary, social security numbers, or credit data. A common pattern is to grant Read on a confidential field broadly, then grant Edit only to the small group that maintains it. Because field permissions are evaluated independently of the page layout, a field can be read-only by security even when the layout would otherwise allow editing.
Read Only on the page layout (and how it differs)
Page layouts have their own read-only setting. When you edit a layout, each field has properties where you can mark it Read-Only or Required. This controls the field only on the detail and edit pages that use that layout. It does not touch related lists, reports, list views, or the API. This is the key difference people miss. Field-level security restricts a field everywhere and cannot be bypassed by the user. Layout-level read-only is a softer control that shapes one screen. Salesforce notes that layout properties only control visibility and edit access on detail and edit pages, while field permissions control the field across the whole app. Because of that scope gap, field-level security is the stronger choice when the goal is real protection. Layout read-only is better thought of as a usability guardrail. It keeps people from typing in a field that a flow or trigger should own, without claiming to be a true security boundary. When both controls apply, the field is read-only on that page either way, so the stricter field-level security still governs the rest of the app.
Read Only at the record level (Public Read Only sharing)
Read Only also describes a record-sharing level. In organization-wide defaults, every object has a baseline that decides how users see records they do not own. Public Read Only is one of those choices. With it, any user can open and view records of that object, but only the owner (and users above them in the role hierarchy, or those given more access) can edit. Public Read Only sits between Private and Public Read/Write. Private hides records you do not own until something shares them with you. Public Read/Write lets anyone view and edit. Public Read Only is the middle ground: full visibility, no editing. It is a good default for reference data that the whole company should read but only a few should change, such as a shared product catalog or company-wide accounts. When the org-wide default is Private or Public Read Only, the Sharing button appears on records so owners can grant extra access through manual sharing or sharing rules. Those rules can raise access from Read Only to Read/Write for chosen groups, but they cannot drop a user below the org-wide baseline.
The "Edit Read Only Fields" system permission
There is one system permission that changes the rules: Edit Read Only Fields. When a profile or permission set has it, that user can edit fields that are marked Read-Only on the page layout, even though the layout says otherwise. It is global, so it applies to every layout-level read-only field in the org for that user, not to a single field you pick. Two limits matter. First, this permission only overrides layout read-only, not field-level security. If a field is read-only because Read is granted without Edit, Edit Read Only Fields will not unlock it. Second, truly system-managed fields stay locked regardless. Salesforce calls out that values like the last modified date and formula fields cannot be edited even with this permission, because the platform owns them. The permission is typically given to integration users or data-loading admins who must populate normally protected fields during a migration. It is powerful and easy to forget, so it belongs on a tightly scoped permission set rather than a broad profile. If users seem to edit fields that should be read-only, this permission is the first thing to check.
Read-only objects and the rest of the stack
Beyond fields and records, an entire object can be read-only for a user. Object permissions on a profile or permission set include Read, Create, Edit, Delete, View All, and Modify All. Granting Read alone makes the object viewable but not editable. The user can open records and run reports on them, yet the New, Edit, and Delete buttons stay unavailable. This is how you give a team reference access to an object they should never change. Salesforce evaluates these layers together, and the most restrictive one decides what a user can do. Object permission grants the broad ability to edit; field-level security narrows it field by field; record sharing controls which specific rows are in reach; the page layout shapes the screen. A user might have Edit on the Account object, Read-only on its Annual Revenue field, and Public Read Only sharing on a record they do not own. The combined result is that they can edit accounts they own, but on this particular record they can change nothing, and even on their own accounts the revenue field stays locked. Reading access top to bottom is the only reliable way to predict the outcome.
Worked example: protecting a salary field
Picture an HR app with a Salary field on a custom Employee object. Most employees should never see it. Managers should see it but not change it. Only the compensation team should edit it. Read Only is the tool that makes the middle case work. Start with field-level security. Hide Salary by clearing Read on most profiles, so it does not surface in reports or list views for them. For managers, grant Read but not Edit, which makes the field read-only everywhere they look. For the compensation team, grant both Read and Edit. Now the field protects itself regardless of which screen, report, or API call touches it. You could also mark Salary as Read-Only on the manager page layout, but that would only cover the detail page, so field-level security is doing the real work here. If the compensation team loads salaries in bulk through a tool and some target fields are layout read-only, an admin permission set with Edit Read Only Fields lets the load write them, while field-level security still keeps managers locked out. This is the layered model in practice: each control owns a scope, and Read Only appears wherever you grant view without write.
How to make a field Read Only with field-level security
The most direct way to make a field read-only for a group of users is field-level security. Here is how to set a field to Read without Edit on a permission set, which is the modern, recommended path over editing profiles.
- Open the field in Object Manager
In Setup, go to Object Manager, pick the object, open Fields & Relationships, and select the field you want to restrict. Click Set Field-Level Security to see every profile and permission set at once, or configure it per permission set.
- Grant Read and clear Edit
For each profile or permission set that should have view-only access, check Read and leave Edit unchecked. Checking Read without Edit is exactly what produces read-only. Clearing both Read and Edit hides the field instead.
- Decide on layout read-only separately
If you also want the field greyed out on a specific page, edit that page layout, open the field properties, and mark it Read-Only. Remember this only affects that one screen, so it complements field-level security rather than replacing it.
- Save and verify as a test user
Save your changes, then log in as a user from the restricted group (or use the View As feature) and confirm the field shows its value but offers no way to edit it on records, reports, and list views.
Lets the user see the field's value everywhere. Granting this without Edit is what makes the field read-only.
Lets the user change the field. Leave it unchecked for read-only access; check it only for users who must update the value.
Marks the field as non-editable on the detail and edit pages of that layout only. Does not restrict reports, list views, or the API.
A profile or permission-set permission that lets a user edit layout-level read-only fields. Does not override field-level security or system-managed fields.
- Field-level security overrides page layouts. A field set to Read without Edit stays read-only even if the layout would let you edit it.
- The Edit Read Only Fields permission only unlocks layout read-only, not field-level security. If Edit is unchecked in field permissions, this permission will not help.
- System and formula fields such as Last Modified Date stay non-editable even with Edit Read Only Fields, because the platform manages their values.
- Public Read Only is a record-sharing level, not a field setting. It controls who can edit whole records, and a user can still be read-only on individual fields on top of it.
Trust & references
Cross-checked against the following references.
Straight from the source - Salesforce's reference material on Read Only.
Hands-on resources to go deeper on Read Only.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What is Read Only access?
Q2. Where can read-only be enforced?
Q3. What principle does read-only support?
Discussion
Loading discussion…