2

I've an interesting issue here with the combination of Trigger and a Workflow Fied Update on the Opportunity object. I do know/understand the Apex order of execution and also the fact that Salesforce triggers both the Before & After triggers if there was a Field Update by a workflow in the same transaction.

So, for an example where there is a Field Update after the 'Insert' operation, we're observing that the Before/After Insert triggers are run again after the field update. (Should this have been a Before/After Update run after WFR field update ?).

The issue: While the actual After Insert operations do provide us with a new Opportunity Id (say Id1), when the triggers are fired again, after the WFR update, the Id(Id2) of the record in the After Insert is different than the one we got in the first iteration (Id2, rather than Id1).

We do have Recursion control code (static boolean) in our trigger handlers and hence, when the Before/After code is run again after the field update, the operations to be performed on this record aren't. While the code logic is performed on the record with Id: Id1, I see that the Id of the record is updated/changed to Id2 during the second iteration and hence any operation performed on Id1 are no longer valid.

I do have specific debug logs that show the Ids are different and also I'm certain that there is only 1 record that is being inserted during my test and not two. Is this expected behavior that salesforce generates a different recordId when the triggers are run after the WF field update ? How do we handle such conditions to make sure I have the trigger handler operations run on the Id2 record as well ?

Sample Trigger execution logs (without all the detail/verbose logs)

CODE_UNIT_STARTED | OpportunityTrigger on Opportunity trigger event BeforeInsert
CODE_UNIT_FINISHED|OpportunityTrigger on Opportunity trigger event BeforeInsert
CODE_UNIT_STARTED |OpportunityTrigger on Opportunity trigger event AfterInsert
    //
    //
    // All the custom logic goes here
    // Accessing the recordId for newly inserted record gives, say Id1
    //
    //
CODE_UNIT_FINISHED|OpportunityTrigger on Opportunity trigger event AfterInsert

// Workflow Field Update
// This triggers Before/After Insert again, in same transaction
// Should the below be a Before/After Update ? rather than Insert again ?
// Iteration 2,

CODE_UNIT_STARTED |OpportunityTrigger on Opportunity trigger event BeforeInsert
CODE_UNIT_FINISHED|OpportunityTrigger on Opportunity trigger event BeforeInsert
CODE_UNIT_STARTED |OpportunityTrigger on Opportunity trigger event AfterInsert
    //
    // All the custom logic goes here
    // Accessing the recordId for newly inserted record gives, say 'Id2' and 'Id1' is no longer valid. Can't even find this Id thru SOQL or in Recycle Bin. May be bcoz the record was not committed to Db yet.
    // Bcoz of recursion control, nothing happens here...
    //
CODE_UNIT_FINISHED|OpportunityTrigger on Opportunity trigger event AfterInsert
CODE_UNIT_STARTED | OpportunityTrigger on Opportunity trigger event BeforeUpdate
CODE_UNIT_FINISHED|OpportunityTrigger on Opportunity trigger event BeforeUpdate
CODE_UNIT_STARTED | OpportunityTrigger on Opportunity trigger event AfterUpdate
CODE_UNIT_FINISHED|OpportunityTrigger on Opportunity trigger event AfterUpdate

Update after question below

This is an issue for us because, in AfterInsert of the Oppty trigger, we determine & assign a Oppty lookup on a child/related record to this newly created Oppty (Hence significance of Id). With the Id1 linked to the child no longer valid, the child is effectively orphaned.

7
  • This is what is mentioned in the docs: A workflow field update that fires on record insert will rerun any before and after insert triggers again—as insert triggers. However I do recollect @sfdcfox's comment here that it was supposed to be update triggers only. But could be possibly still insert? (haven't really tested it out myself)
    – Jayant Das
    Commented May 20, 2019 at 16:33
  • Yes, I did refer to both of your links prior to this post and was still not sure, given that the logs show it still fires Before/After Insert.
    – mereMortal
    Commented May 20, 2019 at 16:42
  • I will still think the behavior aligns to as mentioned in the docs. Will wait to see other inputs here on this question.
    – Jayant Das
    Commented May 20, 2019 at 16:50
  • Sure, in either case, I'd want to know how do we handle such cases efficiently. Specially the case where the Id from iteration 1 is no longer valid and that messes with much of our code logic.
    – mereMortal
    Commented May 20, 2019 at 17:09
  • I am trying to understand why would the Id be significant in this case? If the platform say takes care of persisting the record with the correct Id, you should be still able to fetch the record as required. What is your logic around Ids and where it fails?
    – Jayant Das
    Commented May 20, 2019 at 17:13

0

You must log in to answer this question.

Browse other questions tagged .