2

I've been trying to troubleshoot this problem for awhile and haven't made much progress, so any tips / tricks / answers that you can provide will be appreciated.

Description:

When a Case object leaves a queue (changes ownership from a queue to !queue), increment a field on every case "above" it in the queue.

Apex:

trigger IncrementSkipCount on Case (after update) {

    String QUEUE_ID = '00H30000000oe6Z';   

    for(Case newCase : Trigger.new){
        Case oldCase = Trigger.oldMap.get(newCase.Id);        

        String oldOwner = oldCase.OwnerId;
        String newOwner = newCase.OwnerId;

        if(oldOwner.contains(QUEUE_ID) && !newOwner.contains(QUEUE_ID)){

            List <Case> casesSkipped = [SELECT Id,Skips__c FROM Case WHERE OwnerId = :QUEUE_ID AND CreatedDate < :newCase.CreatedDate];
            for(Case skippedCase : casesSkipped){

                Decimal skips = skippedCase.Skips__c;
                if(skips == NULL){
                    skips = 0;
                }
                skippedCase.Skips__c = skips + 1;
            }
            update casesSkipped;   
        }
    }
}

Problem:

What I am finding is that the cases that were created before the case that was taken from the queue (that is, cases that were skipped) are sometimes having their skip count go up by 2. It seems to occur on cases that have not been skipped before, but it is only infrequently reproducible.

  • 3
    you have a couple of issues to address first -- (1) hardcoded queue ID (replace with a query based on some name, where name comes from a custom setting or the like; (2) you are doing soql inside a for loop and updates inside a for loop. Read up on bulkification – cropredy Jan 8 '16 at 1:55
  • 2
    Do you use field updates? That can cause triggers to run more than once. – sfdcfox Jan 8 '16 at 2:28
  • Possible duplicate of salesforce.stackexchange.com/questions/101812/…, but I'm not going to flag this in case that's not the case. – sfdcfox Jan 8 '16 at 2:30
  • Like corp1645 said, please address hardcoded queueID and make it bulkified. For debugging the issue, check if you have a workflow in the same object which does field update on case, it might cause this. – Victor Jan 8 '16 at 3:08
  • You should use Id type for new and old values instead of the contains method as you may run into case sensitivity issues otherwise. – Adrian Larson Jan 11 '16 at 0:06
2

As @sfdcfox has already pointed out. Trigger is firing twice after update might be the same reason. However, even if it is not - or whatever the root cause is, the solution is the same.

In any util class, define a static variable called inCaseTrigger and initialize it to be false. Then in your code:

trigger IncrementSkipCount on Case (after update) {
    if(Util.inCaseTrigger)
        return;

    Util.inCaseTrigger = true;
    //...

This will eliminate redundant call to your trigger, whatever the reason is.

| improve this answer | |
  • 1
    This solution has issues when the #records DML'd in a transaction exceeds 200; better is to have a set of IDs as the static variable – cropredy Jan 22 '16 at 20:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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