Make Record Read-Only Based on Record Attribute

Let's start with a few examples:

You have a quote and your business process says that once your customer has accepted a quote, it should no longer be editable.

Consider another example: you are storing grading information of students in Salesforce. Once the grades are submitted, no one should be able to edit those records.

How do you solution that? One popular approach was record type and page layout assignment. So, you create a record type exclusively for the purposes of making the record read-only, assign a page layout and make all the fields Read-Only. Then you design an automation where you specify the condition that when Quote Status = Accepted, change record type or in our second example, when Grade Status = Submitted, change record type.

This has been an approach followed for long time and even recently someone suggested the same when we came across similar use case. While this approach was once popular, there are better and more elegant solutions with lesser overhead of maintaining record types, page layouts and automations to switch record types. Also, while page layout assignments and record types will be one of the few things that will remain on profiles post Spring '26 (latest announcement), you still may want to move away from this approach as Salesforce recommended approach is to use Dynamic Forms & Dynamic Actions.

Option 1: Dynamic Forms with Dynamic Actions

Dynamic forms is a recent feature of Salesforce and it's mighty powerful. Dynamic actions have been around for a little longer, if I am remembering correctly. Dynamic forms is one of the reasons to reduce creating record types and page layouts. The way to approach the use cases mentioned earlier in the article, i.e. when a quote is accepted, you no longer want users editing the record, with dynamic forms,

• You create sections in your lightning record page where you'd have editable fields in those sections and those sections are visible only when Quote Status is not equal to Accepted.
• Then, you'd create other sections on the same lightning record page (duplicating the same actions as above) where all the fields in those sections are read-only and these sections would be visible only when Quote Status = Accepted
• Similarly, you control showing or hiding the buttons on the record based on Quote Status using dynamic actions. If you are implementing CPQ, hide Edit Lines, Edit, Submit Quote for Approval, Recall Approval, View Approval buttons when Quote Status = Accepted.

The biggest benefit of this approach is that it provides a nice user experience, especially that it doesn't gives user the illusion that they can edit something when they are actually not supposed (as opposed to the next approach). Another key benefit is that you are not really adding any metadata to control the behavior. The only metadata is the lightning record page which you'd already be creating if you not using the default lightning record page provided by Salesforce. And if the fields are not crazy on the record (again a best practice to keep fields limited on a record so that you have better adoption), building this is actually quote enjoyable and is not a heavy lift.

The drawback of this approach is that since this is controlled at the UI layer and not the data layer, sly users can use tools like Chrome Inspector to make changes to data.

Option 2: Before Save Flows

Flows have become powerful and with each release and before save flows are just one of the many reasons to embrace flows.

Again, for our use case, you'd create a record triggered flow with fast field update that would update a checkbox field on the record which would trigger a validation rule.

Your decision element would say: if quote prior value is accepted, then in trigger an update to check Record Locked checkbox to TRUE. Since this is a before save trigger, validation rule that you put in place will trigger saying, "An accepted quote cannot be modified".

This is on opportunity object but works similarly:

The biggest benefit of this approach over the first approach is that the validation is done at the database layer meaning sly folks cannot bypass the UI to make record updates. The downside is that its a little more metadata compared to the first option. Also, when loading data, care should be taken to deactivate this validation rule. Next, one of the things my mentor would often say is that users are generally put off with the user experience, that is when they feel like they can edit a record but are slapped with validation rules.

So, here we go! Here I've outlined two solutions to making a record read-only based on some of the attributes on the record. Of course, this can be extended to related records. For example, you cannot mark an account as Inactive when it has open opportunities.

Finally, existing customers who have record types, page layouts and automations for the exclusive purpose of making a record type read-only must refactor to take advantage of the latest features of Salesforce and reduce any technical debt.