1

I have several custom fields on the Account object that serve as rollup counts of specific Activities, e.g. Open Task Count, Completed Task Count, etc. I fill these fields via an after trigger on the Task object that involves an update of the parent Account. All works great, ok.

Now for a separate project, I have been tasked with creating a trigger on the Account object that creates a task (within that account) under certain circumstances. This runs into a recursive self-update issue — if the Account trigger creates a Task, the Task trigger then tries to update the Account and of course this is not allowed.

I am aware of the Trigger Pattern for Tidy, Streamlined, Bulkified Triggers, which I can see is very nice but I am honestly just not at the skill level to implement it, nor do I have that kind of bandwidth to learn it at the moment.

So, barring a total re-architecting of my entire org's trigger setup, is there a quicker way to work around this issue?

OBerm
  • 1,224
  • 13
  • 26
  • 1
    see http://developer.force.com/cookbook/recipe/controlling-recursive-triggers – cropredy Feb 14 '15 at 01:32
  • Ah, that's just what I was looking for, thanks for the tip. It's in line with Abbas' good answer below, but with more detail! Cheers-- – OBerm Feb 17 '15 at 18:31

2 Answers2

1

You can create a class which holds a static boolean variable. You've to check the value of variable before entering the trigger. And after the trigger has updated the record, you can set that variable. It will cause the trigger to run only once for one DML operation.

Abbas
  • 675
  • 7
  • 19
0

One way to achieve this is to use filters in your triggers. Your trigger should not only check that the task fits the criteria to rollup, but also that it changed to fit the criteria. If it didn't change, then we don't need to do the rollup again.

Here's a sample:

trigger Account on Account (after update)
{
    if( Trigger.isAfter )
    {
        if( Trigger.isUpdate )
        {
            Set<Id> accountIdsToCreateTasksFor = new Set<Id>();
            for( Account newAccount : trigger.new )
            {
                //To simplify, I'm only going to create tasks for accounts that have a name change
                Account oldAccount = Trigger.oldMap.get( newAccount.Id );
                if( newAccount.Name != oldAccount.Name )
                {
                    accountIdsToCreateTasksFor.add( newAccount.Id );
                }
            }
        }

        TaskCreator.buildTasksForAccounts( accountIdsToCreateTasksFor );
    }
}

For your example, an Account gets updated with a new Name and adds a task. Then your task trigger runs an computes the rollup. When the Account gets updated again, the filter sees that the Name has not changed this time, and does not need to make a task again, thus ending the trigger.

Sean
  • 646
  • 4
  • 8
  • Hi Sean, thanks for the feedback. Currently, my Account trigger only creates a Task if the value of another field ("Account Health") has changed to "Danger" from another value. The Task it creates will change the value of the "Open Task Count" field, so it is appropriate for the Task trigger to run and update the Account. However, the issue comes in the fact that the Account trigger ends up causing a recursive update of the Account itself. – OBerm Feb 13 '15 at 16:28
  • Are there any filters you can add to the Account trigger similar to what I have above? – Sean Feb 13 '15 at 19:45