Salesforce only fires two triggers on merges:

  1. The delete triggers on the merge loser
  2. The update triggers on the merge winner

Triggers do not fire for any children records of the merge loser that are reparented or deleted as a result of the merge.

Why would Salesforce build the system this way? I want to know if it would be a Bad Idea to execute all the trigger logic that would normally execute on child update/delete.

1 Answer 1


Children triggers never fire by default on any operation (update, delete, undelete, or merge). If you want/need these records to be triggered, you need to call those actions manually. The system is perfectly consistent in this behavior. If you want to trigger child record logic, you can do so in the trigger. Depending on what you're trying to do (e.g. trigger an external system), you'll probably want to just queue the action asynchronously.

  • 1
    Here's the full list of operations that don't fire triggers developer.salesforce.com/docs/atlas.en-us.apexcode.meta/… . I guess these operations would be potentially too expensive for Salesforce if the children triggers were fired and so they pass the decision on to the user about what logic should fire.
    – bafuda
    Mar 22, 2016 at 15:48
  • 1
    This seems to be more of a performance choice than consistent with other behavior. The merge operation results in changes to the parent relationship fields on the child objects, which would normally fire triggers (as opposed to something that changed a formula field that wouldn't). It makes sense Salesforce did it this way, but the behavior isn't obvious or expected. Mar 14, 2018 at 16:57

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .