2

I have inherited an after insert lead trigger that calls a future method. Based on the response returned by this method, it inserts records in an object. Lets call this object -LeadCopy__c.

Lead --> AFTER INSERT TRIGGER --> FUTURE METHOD --> insert records in LeadCopy__c

A change requested by the user is that she wants the lead record to also get updated after the future method has inserted records in that object.

1) Future method cannot return values to the calling trigger.

2) If I put another trigger on the LeadCopy__c object to update the primary lead record, it will just result in a mess.

What is the best way to make this change?

Improve this question
3
  • 1
    Trying to understand here, For your #2 approach, why do you think it will create an overhead if you introduce an after insert trigger on LeadCopy__c to update the associated Lead record?
    – Jayant Das
    Commented May 23, 2019 at 18:54
  • An after insert trigger on Lead Copy to update the original lead shouldn't be an issue if done properly
    – EricSSH
    Commented May 23, 2019 at 21:51
  • 1
    Have your future update the record. In your trigger check isFuture and if true simply exit.
    – Eric
    Commented May 24, 2019 at 6:57

4 Answers 4

Reset to default
1

I would approach this as follows:

  1. Add a new custom field on Lead: Is_Copied__c
  2. Before calling @future, verify that Is_Copied__c is false
  3. In @future, insert LeadCopy__c, update source Lead as needed and set value Is_Copied__c = true
Improve this answer
2

One option is to have the future method also make a record update to the Lead in addition to the LeadCopy__c insert.

Another route is with queueable methods A @future method cannot call another @future method but it can execute a Queueable method, which can be chained.

Improve this answer
1
  • Queueable method sounds promising. I'll look into that.
    – abhi
    Commented May 23, 2019 at 19:12
0

After you process the Lead_Copy__c records you need a way to tell the LeadTrigger to not reprocess the leads that kicked off this cycle. To accomplish this, you'll have 2 classes and 2 triggers

  • LeadTrigger
  • LeadTriggerHandler
  • LeadCopyTrigger
  • LeadCopyTriggerHandler

On LeadCopyTriggerHandler, have a method called from your LeadCopyTrigger on the After Insert event. This method does 3 things:

  1. It iterates over the Lead_Copy__c records and gets the set of Lead Ids from the Lead_Copy__c records that were processed by this transaction.
  2. It does a DML on the leads,
  3. It stores these values in a static variable in LeadCopyTriggerHandler called asyncProcessedLeads

Then in your LeadTriggerHandler,if you have any logic in the update calls that you don't want applied to these leads remove any Lead Ids that are in LeadCopyTriggerHandler.asyncProcessedLeads. If you don't have any update triggers on LeadTrigger you can disregard this last bit.

Improve this answer
2
  • This approach appears to be a bit complicated. As of now, I don't have any triggers on the LeadCopy object. Should I introduce them or not?
    – abhi
    Commented May 23, 2019 at 19:13
  • Yeah, you need an after insert on the Lead_Copy__c object to update the Lead recs.
    – PartOfTheOhana
    Commented May 23, 2019 at 19:25
-1

In Trigger Save the Data and Serialize it and pass it as a List to Future Method and decerialize it in future

Improve this answer
1
  • 1
    I've downvoted this because I don't see how this answers the question being asked. Also, begging for upvotes is not acceptable here.
    – Derek F
    Commented May 23, 2022 at 11:27

You must log in to answer this question.

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