In Automation, Blog, Flow, Tips & Tricks

Auto-Lock Records with Process Builder

I eventually get this request at every company I’ve worked with. I want to be able to “lock” a record after some sort of criteria. Sometimes it’s really easy and you’re able to simply create a validation rule that says if the record matches x criteria throw an error. Sometimes, it can be more complicated than that. My favorite reason is they want to prevent the user from editing the record at all, not just throw an error when they try to save the change.

Their argument is valid, their point is it’s more user friendly and a better user experience to prevent the user from using the edit button than allow the user to enter the edit screen, make a bunch of changes, and then get frustrated by receiving an error.

This method can be really useful for records that have a high compliance need. Records that absolutely you don’t want people to edit after the records meets your criteria.

The Components

There are only two items we need:

  1. Approval Process to lock the record
  2. Process to Submit Record to the Approval Process

Approval Process

The Approval process is very simple. We’re going to use a formula as the Approval criteria. The formula is simply going to be “false.” This way a user cannot accidentally submit a record into this approval. It will only be submitted using the process we created.

We’ll also only have a single Approval Step. We’ll have all records enter this step and if it doesn’t meet the criteria we’ll approve the record. Again, we’ll use a formula for the step criteria and make it false. This way every record that gets submitted will fail to meet the step criteria and just get approved.

Approval process with a single step

Approval process with a single step

Process Builder

The Process is also going to be really simple. Whatever your criteria is for when you want to lock the record you should set as the criteria node. That’s the blue diamond – think of it like a Workflow rule.

Next, we’ll need to add an action. We’ll add the action “Submit for Approval.” We’ll select a specific approval process, the one we just created. Here’s the important part, you’ll want to check the box to skip the entry criteria. Remember, the entry criteria would not accept any record. By skipping the criteria for the Approval process the record will get run through the approval steps.


Process Builder to submit for approval

Process Builder to submit for approval


That’s it! We’re done! Isn’t that simple? Now you can lock the record from editing whenever a record meets a set of criteria without having to write any validation rules.


Anyone who as “Modify All” on the object will be able to “unlock” the record to edit it. You may want to enable track history so to capture who unlocked a record.

You can also put a “delay” in the record locking. Instead of making it a “immediate” action, you can schedule the action based on some date on your record.

Recommended Posts
Showing 4 comments
  • Kristi G

    This seems interesting – is your use case that the record should then be locked forever? IE: A week past the Close Date on an Opp, it can no longer be modified?

    • Brian Kwong


      You’re right or for a long period of time that requires someone with “modify all” perms on that object to “unlock” the record.

      It could be something like a authorization request or maybe a expense report.

      Or like you said you want to make sure the Opportunity cannot be edited after some set of criteria.

      • Donna

        I like this solution, but what if you want a user to be able to unlock the record with a status change (for example)? I’m struggling to solution this.

        I have a requirement to prevent the ability to edit a case record if the Status = Closed BUT the user should be allowed to change the Status to Reopen, at which point the record is editable.

        • Brian Kwong

          I wouldn’t use process builder & Approval process to lock your record in this example.

          I would use validation rules and custom permission to provide exceptions (

          I would use two rules. One that prevents the edit on ANY field except Status. So your validation rule is literally just Text(Status)=”closed” (plus your custom permission if you want to do that). The second rule would control the Status field where it’ll error if the status WAS Closed and is set to anything other than reopen. So something like TEXT(Status)<>“Reopen” && PRIORVALUE(Status) = “Closed” (plus custom permission if you want to do that)

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.