[SalesForce] Prevent related record deletion, except when parent record is being deleted

I have two custom objects, call them Parent and Child. Child has a Lookup to Parent, via Parent__c. It is not a Master:Detail relation.

What pattern could I use to prevent deletion of a Child record by users, except in cases where the Parent record is being deleted? In other words, I would like to implement a cascade delete, but not allow users to delete Child records themselves.

Should I simply accomplish this by revoking Delete permission on Child, and implement the cascade delete in a trigger on Parent? What is the best practice?

Best Answer

I think you can achieve it in two ways including the one you mentioned.

1) As you suggested, remove delete permission on child. It will remove delete option on child. Then write trigger on parent, to delete child also, when parent is deleted. This would be the best approach.

2) Write trigger on both child and parent. child trigger will prevent deletion by record.addError(). Then in parent object trigger, you can delete child records also.

Related Solutions

[SalesForce] Delete Operation Too Large – but all related records have been deleted

You must wait between several days up to a week in order to delete the parent record. Even if you empty the recycle bin, the records are not "permanently" deleted until some reaper job on the Salesforce side runs to truly delete them.

If you're in a rush, you can open a case with Salesforce asking to "run a physical delete" on your org. They will require that you agree to empty your recycle bin first.

The deleted records don't count toward your data storage limit.

We have worked around this problem by setting a 'status' field on the parent object to indicate that we want it deleted. After we delete all of the child records, we set the status to 'Deleting'. Then, create a Scheduled Apex job that runs around nightly trying to delete the parent records that are in that status. You must rescue the possible exception and carry on. Sooner or later, the records can be deleted.

Last caveat: sometimes the org gets corrupted and even the 1 week rule doesn't hold true. In that case, you will need to open a case and have them escalate it to R&D for physical deletion. This is rare, but it does happen.

The bit of Scheduled Apex we use looks something like:

List<SupremeQueryResult__c> deletedSnapshots = [SELECT Id FROM SupremeQueryResult__c
                                                WHERE Status__c IN('Deleted','Deleting')];
for(SupremeQueryResult__c result : deletedSnapshots){
    try{
        delete result;
    }
    catch(System.DmlException dmle){
        if(dmle.getDmlType(0) != StatusCode.DELETE_OPERATION_TOO_LARGE){
            throw dmle; //reraise
        }
    }
}

[SalesForce] Enabling Editing/Deleting others’ Tasks without “Modify All”

There's no general "configuration-only" solution to this problem. You'll need a way to bypass sharing to allow deletion. Here's some choices (some of which are already noted in the comments):

Custom REST/Web Service

Write a "webservice" method, or a @RestResource method. Use "without sharing" to bypass sharing on the tasks.

Visualforce

Write up a page that allows deletion of a specified task. Works the same as above, but uses Visualforce instead of JavaScript.

Trigger

You can actually delete a record in a trigger using "after update". Just make a custom checkbox and have the trigger delete the record when checked. Users will only be able to delete tasks they can edit using this method.