3

My organization protects certain fields on Contacts of Record Type X from being edited, as these contacts are imported from an external system. In addition to using locked-down page layouts, we have a trigger as another layer of security--so if a user does manage to edit one of these fields on a Contact of Record Type X, we won't allow him to save the record.

We've hit a snag with Lead conversion to an existing contact. Lead conversion will not /overwrite/ fields on an existing contact, but it will populate fields that are blank on the Contact. This causes our trigger to fire and creates a bad user experience, because the user has to go back to the lead and clear the field. What we really want is to permit the lead conversion without allowing/keeping the updates.

The best solution I can think of is to alter the existing trigger to permit Lead conversion to write to these fields and then immediately roll it back to the previous (blank) value. How can I tell definitively that an update to an existing contact was caused by a Lead conversion? I know the old trick with the "2 checkboxes" Rube Goldberg machine, but that doesn't work if the contact already existed.

Improve this question

1 Answer 1

Reset to default
1

Interesting one!

  1. What if you ad a public static Boolean isRunning variable to a Lead before update trigger and then in Contact trigger check it's value? Set it in before, clear in after... Bit crude, might allow false positives if you have some cascading updates of Contacts that touch other Contacts... But could work.

  2. Alternatively you could check if "this" contact's Id value is somewhere in Lead.ConvertedContactId field. This might be a royal pain in the ... to implement because I imagine behind the scenes upsert of contacts happens in before update of Leads so the Id is not saved to DB yet (in fact - possibly not known yet). Also - how would you be sure that's indeed this lead that's being converted right now, try to grab it with SELECT ... FOR UPDATE? Messy.

  3. Last but not least - have a hidden checkbox on Leads (always enabled), map it in conversion, if your Contact trigger sees it - don't throw errors but just clear the checkbox so it's never possible to actually save it on the Contact... Is that the Rube Goldberg one you're thinking about? ;)

Go with #1 I'd say.

Improve this answer
6
  • I like a variation on #3 -- custom field on Contact Is_Originated_From_Lead__c that is mapped to true in Lead Field mapping from custom Lead formula field Is_Lead__c defaulted to TRUE
    – cropredy
    Commented Oct 4, 2017 at 21:51
  • @cropredy wouldn't that become a blanket "anything's possible, from now on edit what you want" after 1st conversion that updates the contact?
    – eyescream
    Commented Oct 4, 2017 at 22:37
  • @copredy It's an existing contact that may or may not have originated from a Lead. The trick is not letting a /subsequent/ conversion write to anything.
    – A. Miller
    Commented Oct 4, 2017 at 22:40
  • ah - right - I was blinded by my past practice on verification during insert of new Contact (not update of existing) - but you should be able to leverage the signal from the Lead Mapping fields that Contact has changed due to Lead Conversion (custom field + createdDate != lastmodifiedDate) @AMiller
    – cropredy
    Commented Oct 5, 2017 at 0:14
  • You guys are great--thank you so much. I was stuck. In the short term we're doing a silent rollback for all users (not for long because I don't like rolling back with no validation message). Then we're going to restore the validations with conditional behavior for lead conversion, trying eyescream's #3 (it had not occurred to me to just clear the checkbox and bypass the problem of it already being set to True) and @copredy 's comparison of created and last modified, to see which works best. Thanks again.
    – A. Miller
    Commented Oct 5, 2017 at 20:18

You must log in to answer this question.

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