Validation rule on delete

Ideas & Features
1

Just like there’s validation rules for create and for edit, it would be great to add validation rules on entity delete. Where you can only delete the entity on certain conditions.

Note that this could also be solved by preventing “Unlink” updates, I think.

2

Hey @RonMakesSystems, are you aware of any better workarounds for this at the moment?

The best I can think of is this:

  1. Create a duplicate (Database_1_Copy) of the database (Database_1) where you want to restrict deletion
  2. Have an automation that makes a copy of each entity in Database_1 into Database_1_Copy
    • These “copy” entities will have a one-to-one relation to the corresponding entity in Database_1
  3. Have a validation rule that runs when the “Linked Database_1 Entity” field is updated in “Database_1_Copy”

Simpler setups would be possible but (as I’m sure you know) unfortunately validation rules can only run on one-to-[many/one] fields, not many-to-[one/many] fields, hence the need to create a separate entity for each Database_1 Entity

3

Hey! This solution may work actually, but it’s indeed not so elegant. It really depends on your setup, but there are 2 other options that may be a bit cleaner:

  1. If you have a one-to-many, you can use validation rules to prevent unlink from the “one” side of the relation. Note that this prevents unlink, not just delete.
  2. You can make a custom database access level for “Editor without Delete”, then have the delete access controlled via entity level access templates, where you give the users an access template with delete access only if a certain condition is met. This prevents the delete itself, and isn’t dependent on any other relation, but is a bit more annoying to set up. (and doesn’t prevent admins from doing whatever they want)

Those are the two options I would personally reach for before duplicating the full db.

What do you think of option 2? It sounds like you may have a many-to-many relation based on what you’re saying.

4

Thanks for the suggestions! These are really useful. This is mainly for a many-to-many database, and it would be good to have some protections against admin deletions too, but these will be helpful for other databases and users.

Thanks, Ron!

5

No worries!

In which case, I think what you found is quite a smart was around it. Just to clarify, when you say:

Do you copy all the fields in the Database_1_Copy? Or is it just a database with a single one-to-one relation for every Database_1 entity?

I tested it with the latter just now, (A “Deletion Preventor” Database, which can be related to anything you want) its actually more elegant than I gave credit for. Might steal this :wink:

My main reservation was needing to maintain a mirror of the database with all fields synced, but there’s actually no need for that, maybe I misunderstood.

Also, just be aware that the users can technically still circumvent this by creating a private viewing showing both databases, selecting both the Database_1 entity and the Database_1_copy entity and deleting them at the same time. Might not be a problem, but in case you didn’t know.

Ideally we get proper “On delete” trigger for validation rules some time soon :))