This is a follow up to my earlier post where we learned how to allow non-admins to edit approved records by leveraging Custom Permissions and Validation Rules. In this post we learn how to lock down the related lists once the record becomes approved using similar technique.

According to Salesforce documentation, the standard functionality of an Approval Process is to lock the record and any child records in a master-detail relationship with it. Child records that are linked to the parent via lookup relationship only are not locked.

Only Use Master-Detail Related Lists (not really)

One approach is to ensure all your related lists are related to the parent object via master-detail relationship.

However, that design philosophy is not very practical or feasible in all situations.

Knowing this, there are multiple ideas on the IdeaExchange asking for greater control from being able to choose which related lists get locked to enforcing all related lists get locked.

idea_choose_related_records_lock_or_not.png

idea_lock_all_related_records.png

Lock Existing Records with Apex

To handle non master-detail related lists then we need to roll our own solution to lock them. Apex offers a method to lock records using code and Ratan Paul offers an example approach by writing Apex triggers to lock records. By doing so the child records are locked with same strength as the parent record and any attempt to edit them will display the Record Locked error page.

approval_record_locked_error

However, this only handles locking existing records. And it requires code.

What do we do about attempts to create new records?

Block Create or Edit of Records with Validation Rules

To block users from creating or editing records, Bob Buzzard offers up tried-and-true no-code solution of using custom fields and validation rules.

The gist of the solution is that either when the record becomes submitted for approval or becomes approved then use Workflow Field Update fired by Approval Action to set a value on the approved parent record indicating such (e.g. checkbox or picklist). Then on your child objects you can introduce Validation Rules that check the parent object’s field value (e.g. is the checkbox checked? is the picklist a specific value?) and decide to show error message or not, effectively blocking the user from creating new or updating existing child records.

However, this only handles creating or editing records.

What do we do about attempts to delete records?

Block Delete of Records with Rollup Fields

Since we’re focused on non master-detail related lists then I’m not referring to the standard Rollup Summary fields (which only work with master-detail relationships) but I am referring to the same concept.

The idea is to create a number field on the parent object to store the count of child records. You would repeat this for as many related lists that you wanted to prevent deletion of records.

Then using a free app like Andy Fawcett’s Declarative Lookup Rollup Summaries tool or Passage Technology’s Rollup Helper you configure automation to calculate the parent record’s rollup field value. As your users create or delete child records then the rollup field value changes.

Similar to the “Block Create or Edit of Records with Validation Rules” solution we just discussed, layer in another Validation Rule on the parent object that checks two conditions:

  1. Is the record approved? (e.g. is the checkbox checked? is the picklist a specific value?), and
  2. Are any of the rollup field values changing? (if incrementing the new child records are trying to be created, if decrementing then existing child records are trying to be deleted)

Your validation rule might look like this:

AND(
  Is_Approved__c, /* checkbox checked by approval process field update */
  OR(
    ISCHANGED( Rollup_Child_Object1__c ),
    ISCHANGED( Rollup_Child_Object2__c )
    /* continue for as many related list rollup fields */
  )
)

Conclusion

It is non-trivial to lockdown non master-detail related lists when the parent record is approved. However, with some creativity with custom fields to indicate the parent record is approved and rollup counts of child records then you can easily leverage validation rules to block users from creating, updating, or deleting child records.