You need to sign in to do that
Don't have an account?
Jon Keener
Determining in trigger for before delete (or before update) whether Merge is the cause
Is there anyway to determine in a before delete trigger if the reason that a delete is because a user is attempting to merge a record, and the record being deleted is the losing record in the merge? The reason I'm asking, is I would like to show a different error message, depending on the context. (merging, vs. clickling the delete button on the account.)
Also, I was thinking about whether there might be value in have "before merge" and "after merge" triggers. These might be useful, for example, being able to look at something like trigger.old.1.name, trigger.old.2.name, trigger.old.3.name, and trigger.new.name.
Rules could be put in place to not allow certain types of field merges from certain types of records. For example:
1. I want to allow users to merge prospect recordtype accounts to customer recordtype accounts, but not the reverse.
2. I do not want to allow customer recordtypes to be merged with other customer recordtypes. (In our case, we have an integration with SAP, and we want SAP to have full control over this)
3. When merging a prospect recordtype to a customer recordtype, I do not want certain fields from prospect records to ever merge to a customer recordtype. These would typically be fields that are prepopulated on the customer recordtype from our SAP system.
As for your use cases, are your rules actually different in a merge event, i.e you allow prospect to customer change when it's a merge event but not an update? Unless there is a difference then your rules should apply as expected in the Update trigger on the winner.
If SAP is the master, won't the values get written back over? Sounds like you want those fields to be readonly in salesforce no matter what, again either in a merge or a direct update, right?
We've debated whether to have triggers for merge events but so far we've been able to justify use of the existing delete/update events that result - which also means fewer trigger states for developers to worry about.
If you have different logic you'd enforce on the update based on the operation being a merge please include them here.
Thanks,
As for different logic between a merge and an update, I haven't thought of any specific scenarios, that couldn't be handled via the standard update/delete triggers, assuming they are working appropriately. One that I need to think about a little more is recordtype changes, during a merge.