Is there a way to avoid deletion of records using validation rules?

No — validation rules cannot prevent record deletion. They only run on insert and update events. The “delete” path goes through a separate part of the order of execution, and validation rules aren’t invited.

This is one of the most common interview catches for admins moving toward developer questions. The right answer pairs the “no” with the three legitimate alternatives.

Why validation rules don’t fire on delete

Validation rules are formula-based and the formula operates on field values. At delete time, the platform doesn’t need to re-check the record’s content — it just needs to know whether the user has permission. So the validation pipeline is skipped entirely.

The three ways to actually block deletion

1. A before delete Apex trigger

The standard approach. The trigger inspects each record and calls addError() to abort:

trigger AccountTrigger on Account (before delete) {
    for (Account a : Trigger.old) {
        if (a.Active__c) {
            a.addError('You cannot delete an active Account. Deactivate it first.');
        }
    }
}

The error displays to the user just like a validation rule error.

2. Permission-based — remove “Delete” from the profile

If the rule is “no one but admins can delete this object, ever”, the cleanest fix is to remove the Delete permission from the object on every non-admin profile. No code needed.

3. Sharing rules / record types / approval lock

• An approval process locks the record once submitted; locked records can’t be deleted.
• A Flow Orchestration workflow can lock records during a multi-step process.
• Record lock via Approval.lock(record) in Apex offers programmatic control.

What about flows?

A Record-Triggered Flow can be configured to run on “A record is deleted” — but only after the delete. You cannot abort a deletion from a Record-Triggered Flow. So flows are not a real answer here either.

What interviewers want

• A confident “No” with the reason: validation rules don’t fire on delete
• A pointer to before delete triggers as the standard mechanism
• Bonus: mention permission removal as the no-code alternative

Related follow-up

• What is the order in which Salesforce processes rules? — explains where validation sits in the save pipeline and why delete is a different code path.

Verified against: Apex Developer Guide — Triggers and Order of Execution. Last reviewed 2026-05-17 for Spring ‘26 release.