Imagine this scenario: a non-administrative user is walking you through a common process in their Salesforce environment when suddenly, they modify a field that should not be editable to them. As this is undoubtedly an issue with user permissions, you first check their profile and permission set assignments. To your surprise, the user appears to still be assigned to the correct profile and permission sets (i.e., the user has not been inadvertently given an Administrator profile). As no custom components have been added to any pages, you know that the issue must lie within the profile or the permission sets themselves. Digging further, you find that object-level access, field-level access, and page layout assignments are all set as expected. By everything you have reviewed so far, the field should not be editable to the user.

After more investigation, you finally determine that the culprit is a permission rarely discussed within the Salesforce community: Edit Read Only Fields.

What is the Edit Read Only Fields Permission?

The Edit Read Only Fields permission is available through Salesforce licensed Profiles and Permission sets — it is selected by default on the standard System Administrator profile. Unlike the “Modify All Data” permission, it does not require any other permissions to be enabled. A person that has this permission will be able to edit any read-only fields (as set by page layouts or field-level security) on ALL objects that they have been granted edit access to.

This table shows the access of a given field from the perspective of a user attempting to edit the field on a page layout without any additional custom buttons, actions, components, or automation.

This permission persists with data import tools like the Data Loader, which require the API Enabled permission to use. Let’s say a user has the API Enabled permission along with edit access to an object. This object has an external ID field that has been set to be Read Only for the user’s profile. With the Edit Read Only Fields permission, the user would have the ability to mass update this “Read Only” external ID field.

What Makes this Permission so Appealing?

There are many scenarios for which an administrator would want to remove edit access to a field for some users and not others. Between object-level security, field-level security, page layouts, profiles, and permission sets, Salesforce provides a multitude of ways to achieve this. For large organizations with diverse security needs, the Salesforce security model configuration can quickly become complex and challenging to maintain as business needs continually grow and change over time.

For an overwhelmed administrator, it can be appealing to simply enable the Edit Read Only Fields permission on a profile or permission set as a quick fix instead of creating new record types and page layouts. This is especially tempting for organizations with an excess of legacy page layouts and record types. However, consider that the Edit Read Only Fields permission grants the ability to edit read-only fields on ALL objects to which the user has edit access. If utilized irresponsibly, the Edit Read Only Fields permission can easily compromise the security needs of any organization.

What is the Long-Term Impact of this Permission?

Administrators must be wary of the impact that assigning the Edit Read Only Fields permission will have on future customization efforts within their Salesforce org. For example, the business could later require a field for which users with the Edit Read Only Field Permission will need to see but never edit. This is common for fields that are calculated and set through custom automation tools such as Workflow, Process Builder, Flow Builder, and Triggers. Depending on how the field is used, providing a bit of guidance around appropriate usage of the field for these users could be sufficient. However, if the field is included in executive reports or used to influence major business decisions, an administrator might need to reconfigure the security model entirely to prevent any accidental edits to the field.

Can this Permission be Beneficial Outside of an Administrative Team?

It’s worth highlighting that there might be organizations with specific requirements where usage of the Edit Read Only Fields permission outside of an administrative team is beneficial. For instance, some organizations have users outside of the administrative team that perform regular audits and should always be able to edit any piece of data in the org. This permission can also be useful for certain types of managerial teams who are comfortable working within the system and need the ability to freely modify data in order to maintain clean and accurate reports.

What are the Alternatives?

Given the potential security concerns around the Read Only Fields permission, Salesforce Administrators should always consider alternative solutions to this permission before implementing it. As mentioned earlier, administrators working in orgs with overtly complex or convoluted security models will be especially tempted to use the Read Only Fields permission as a quick fix. In the long term, this “quick fix” will only exacerbate the complexity of the model.

Overall, it is important to have recurrent security model reviews to streamline where possible. These sessions can take place annually or even bi-annually depending on the size of the Salesforce org and the volume of periodic customization requests. Check out the App Exchange for useful tools to easily visualize and examine current user access in the system. Take advantage of field-level security, record types, and page layouts to accommodate security needs. Alternatively, consider using solutions such as a Permission Set that grants edit access to specific fields, instead of the Edit Read Only Fields permission to accommodate incoming business needs. Custom actions or buttons that launch a flow may also be a great alternative. As a best practice, only extend permissions to users on an as-needed basis to reduce risk.

Author:
Jasmine Brownis a Salesforce Consultant based in Phoenix, Arizona. She is a Salesforce Certified Administrator, Platform App Builder, Service Cloud Consultant, and CPQ Specialist. She has been working on the Salesforce platform since 2014.

About Slalom:
Slalom is a modern consulting firm focused on strategy, technology, and business transformation. In over 35 markets around the world, Slalom’s teams have autonomy to move fast and do what’s right. They’re backed by regional innovation hubs, a global culture of collaboration, and partnerships with the world’s top technology providers.