I am having a use case where I've to do both Trigger and workflow field update.

There are 2 objects. One is Case and other one is Case_child__c and Case is master and other is child.

I'm having an issue, where a Case Trigger is calling a method caseAssistanceMethod. There we are inserting new Case_child__c record based on some conditions. (Business Logic)

trigger Case_afterUpdate on Case (after update) {

    CaseTriggerUtils.caseAssistanceMethod(Trigger.new, Trigger.oldMap);  

 Public class CaseTriggerUtils {

    public static void caseAssistanceMethod(List<Case> newCaseList, Map<Id, Case> oldCaseMap){

       // Here we are writting our business logic.


But, here is my question, above logic is working fine unless there is no workflow field update. If we have any workflow which is updating any Case field, then After_Update Trigger on Case is getting called again.

Because of this I am getting duplicate Case_child__c records. Where I 'm supposed to get only single Case_child__c record.

So, is there any design where we can do both Trigger call and workflow field update on Case, without creating Duplicate Child Record.

  • I agree with Mahat. I particularly like the solution provided by @RajatPaharia at the bottom of the page Mahat pointed you to. – crmprogdev Jul 9 '14 at 19:52
  • 1
    @crmprogdev that pattern does have a hole, albeit not usually in issue, if the trigger logic does need to fire multiple times, i.e. if you had a recurring case and wanted to create a clone when certain conditions were met, if that case met the conditions for case_child__c creation only the first case would get one and not the clone. It's a stretch but the implementation to catch all cases is simple enough you might as well do it. – Ralph Callaway Jul 9 '14 at 22:14
  • Thanks for sharing the caveats that can come back to bite Ralph. I always love the little nuances that I pick up and learn here as others share. As you say, that one is indeed a very simple implementation for a situation such as this case. – crmprogdev Jul 9 '14 at 22:50

I have had this issue in the past, basically you have a recursive trigger. There is a design pattern to handle this and it is highlighted in the excellent book by Dan Appleman (check it out on here).

Link to another question with guidelines on how others have approached the same problem.

| improve this answer | |

You've run into trigger recursion. The simplest approach to this is to add a static variable to your Case class that track which IDs have been processed and doesn't process them a second time. This will work well for you case since you only want to do the operation once for each case.

If you want to get really cool, you can use what I call a trigger old map override. Basically you cache the values you see in trigger new and use those in place of trigger old, so the next time the object is seen you can evaluate whether the changes from the last trigger execution lead to the condition. This is critical if you're tracking field changes, e.g. counting how many times the opportunity stage has changed. For instance a user might change an opportunity stage (count goes up by 1), then a workflow changes the stage again (count should go up to 2). With just tracking the ids, the second change would get ignored, but by caching trigger.new you can see the second change and process it as you see fit.

For code examples see this answer

| improve this answer | |

Not the answer you're looking for? Browse other questions tagged or ask your own question.