Could someone who knows better verify:

I just tested and it seems to me that if I merge -

  • Account 1 with 2 opps (destination)
  • Account 2 with 3 opps

...that the resultant Account 1 with all five opps does NOT benefit from having the Opps it obtained actually being "touched" (updated, edit/save, etc) officially (so no triggers/etc run). Is this true?

Is there a simple way to make this happen, perhaps a simple trigger that would say "if I detect my AccountID has changed, touch me" (at the Opp level)? Since it's not doing it by default, I am unclear how to code such a thing if SF itself doesn't even recognize that the Opp record has been updated (AccountID reference has changed after Merge).


1 Answer 1


From the Apex Developer's Guide:

Merge events do not fire their own trigger events. Instead, they fire delete and update events as follows:

Deletion of losing records A single merge operation fires a single delete event for all records that are deleted in the merge. To determine which records were deleted as a result of a merge operation use the MasterRecordId field in Trigger.old. When a record is deleted after losing a merge operation, its MasterRecordId field is set to the ID of the winning record. The MasterRecordId field is only set in after delete trigger events. If your application requires special handling for deleted records that occur as a result of a merge, you need to use the after delete trigger event.

Update of the winning record A single merge operation fires a single update event for the winning record only. Any child records that are reparented as a result of the merge operation do not fire triggers. For example, if two contacts are merged, only the delete and update contact triggers fire. No triggers for records related to the contacts, such as accounts or opportunities, fire.

The following is the order of events when a merge occurs:

  1. The before delete trigger fires.

  2. The system deletes the necessary records due to the merge, assigns new parent records to the child records, and sets the MasterRecordId field on the deleted records. ) 

  3. The after delete trigger fires.

  4. The system does the specific updates required for the master record. Normal update triggers apply.

Thus you could have a before delete trigger on the deletion of the losing records and figure out the children that will be affected. I suspect that you might need to have some co-ordination between the before and after delete triggers, such that the before figured out the affected children of a delete, and the after confirmed that they were being deleted as part of a merge and took appropriate action.

  • But what if I need the Opps to be "touched" AFTER the Merge? I'm thinking maybe After Delete would work possibly, but am not sure. The Trigger in question updates key fields on the ACCOUNT using the OPP data, so the winning/surviving Account needs to benefit from the newly acquired Opps.
    – AMM
    Commented Jan 3, 2013 at 18:33
  • How about this... it seems like it would be possible to do an "after delete" on the Account (which is what is merged), and tell it to simply update (no real edits) every child opp. That would cause the trigger to fire that I need. Does this make sense? It does to me. I mean, we're talking about what sounds like a simple SOQL query of all child opps (even if it includes the ones that already existed, that's fine) and simply "update" on each record.
    – AMM
    Commented Jan 3, 2013 at 18:59
  • @Bob_Buzzard, let me ask THIS: Does step 4 of what you quoted mean that Triggers that need to fire per the norm on the Account that was MERGED TO will run? If so, that may be my way in to doing what I need.
    – AMM
    Commented Jan 3, 2013 at 20:39
  • I think so - an update event will fire for the "winning" record of the merge (the account that all of the opportunities are reparented to), so at that point you could "touch" each of the opportunities. What you could also do is carry out the update of the account at this point, based on querying information back from the opportunities. The trick will be identifying that an update is due to a merge as opposed to a regular change on the account. Commented Jan 3, 2013 at 21:43
  • Ultimately your quote helped - I did write a simple trigger so that if an Account is edited, it cycles the Opps and touches them. Unfortunately I'm creatimg a cyclic situation which SF clearly tells me about since the trigger I WANT to run edits the Account (which my new trigger reads and triggers the wanted trigger, which edits the Account, which.... get it?) (sigh) I'll have to rethink this. I'll post anew if I find out something better unless someone comes up with a better idea. I tried Before Update, After Update, neither will work due to the cyclic relationship.
    – AMM
    Commented Jan 3, 2013 at 21:43

You must log in to answer this question.

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