function readOnly(count){ }
Sign Up ›
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
Learn More

Browse by Topic
ShowAll Questionssorted byDate Posted
+ Start a Discussion
uptime_andrewuptime_andrew 

APEX Trigger causing Case Assignment Rules to re-fire

I have an APEX Trigger that runs when a Task is created/updated, so it can update the related Case. 

 

Somehow, the trigger is causing the Case Assignment Rules to re-fire, but I don't know what.  Any thoughts?

 

 

 

trigger caseLastActivityDate on Task (after insert, after update) {

    Map<String, Task> tMap = new Map<String, Task>();

    for (Task t : System.Trigger.new) {
        
        String whatId = t.WhatId;

        System.debug('whatId is ' + whatId);
        
        if(whatId <> null && whatId.startsWith('500') == true) {
            Case c = [select Id from Case where Id = :whatId];  

            if(c.Id <> null) {     
            	c.Last_Activity_Date__c = t.LastModifiedDate;   
            	update c;         
            }
        }
    }

}
 
 
 


Best Answer chosen by Admin (Salesforce Developers) 
uptime_andrewuptime_andrew
The solution I had for this was two-fold:
 
First, we added a new field, "Case Taken", which is just a boolean.   Once the case is taken by a user (who is not the default assignee), Case Taken is set to true.
 
Second, we updated the assignment rules with an new entry/step where if Case Taken equals True and the owner is not the default assigner, use the "Do Not Reassign Owner" flag. 


All Answers
jeffdonthemic2jeffdonthemic2
It probably has something to do with the order in which Apex executes. Check out the order of execution and see if you can track down some other triggers that are causing changes or perhaps workflow updates that are kicking off the trigger to fire again.
 
Jeff Douglas
Appirio, Inc.
http://blog.jeffdouglas.com 
 


uptime_andrewuptime_andrew
Thanks for the reply, Jeff.
 
The odd thing is that we have had numerous triggers running on before/after insert/update actions on the Case records themselves, and these have never caused the Assignment Rules to re-fire.  Only the recent addition of the trigger on the Task has this happened.  Reviewing the "Order of Exectution" doesn't provide an explanation. 
 
Thus far, SF Premier Support has not been able to provide any explanation on why this is happening on the Task but not the Case.
 
I'm currently toying with the idea of putting in a hack for our Assignment Rules just so we can set the trigger live again (I've removed it since the re-assignment was causing problems for us), but am hoping there is an explanation & solution around this first.
 
Thank you
 


rtscottrtscott
I'm having the exact same problem, but my trigger is on the EmailMessage object. Everytime a new email message gets attached to an existing Case (through Salesforce's Email-to-Case mechanism), the Case Assignment Rules run again, and the Case is taken from the owner and put back into the queue. Here's my trigger code:


trigger updateSansEmail on EmailMessage (after insert, after update) {
  // Build a list of Case IDs to query against
  Set caseIds = new Set();
  for(EmailMessage e : Trigger.new) {
      caseIds.add(e.ParentId);
  }
 
  // Create a map of Cases with ID as the key
  Map caseMap = new Map([Select Sans__c From Case Where Id in :caseIds]);

  // Iterate the Emails and update each parent Case
  for (EmailMessage e : Trigger.new) {
       if(caseMap.containsKey(e.ParentId)) {
          caseMap.get(e.ParentId).Sans__c = System.now();
       }
  }
  
  // Update the Cases
  disableCaseProcessing.isCaseUpdate = true;
  update caseMap.values();
}

Did you ever find a solution to this problem?

 
-- Rob 
Message Edited by rtscott on  03-20-2010 09:40 PM


uptime_andrewuptime_andrew
The solution I had for this was two-fold:
 
First, we added a new field, "Case Taken", which is just a boolean.   Once the case is taken by a user (who is not the default assignee), Case Taken is set to true.
 
Second, we updated the assignment rules with an new entry/step where if Case Taken equals True and the owner is not the default assigner, use the "Do Not Reassign Owner" flag. 
This was selected as the best answer
rtscottrtscott
Thanks - I'll implement a similar fix. It would be nice to know why the Assignment Rules are re-run in these scenarios when they are not in others. We have a trigger on CaseComment that does the exact same thing as my EmailMessage example, but it doesn't cause the Assignment Rules to re-run.
 
In any event, I appreciate you following up with details on how you solved the problem.
 
-- Rob 


RomyRomy
I have a similar problem where when a User closes the case, a second Email is sent to Queue members from his own Email Account and the content of this email are same as of New Email Notification that is used to sent to Queue member at the time of Case Assignment to Queue when the case is created for the first time. This means case assignment rules are firing here again.


 


Actually we are using before Update trigger on Case to Change Case Owner to Queue (one from which it is accepted) once it is closed. I think this switch of case owner through this trigger is causing the Case Assignment to Refire. As per my knowledge, they should fire only once when the case is created.


 


I will appreciate if someone suggest how to stop this recursive firing of Case Assignment Rules.


McFitz13McFitz13
I opened a case with Salesforce on the assignment rules firing twice because it's causing some of my cases to be assigned to the wrong queues and it was communicated to me it was a bug that would take a major release to fix (and not Summer '10).


 


I also forwarded them this post as well to show other customers were experiencing similar issues. 


 


 


beaugordonbeaugordon
Same problem here - using an afterinsert trigger on casecomment to update a case.  I'm glad I found this thread - I thought I was losing my mind.


 


I'll be implementing a similar solution, setting a flag to trigger an assignment rule with 'do not reassign owner' checked.


mikefitzmikefitz
Bug is scheduled to be fixed in Winter '11


Gil Zilberstein 2Gil Zilberstein 2
Was this ever fixed? I'm having the same problem with the process builder now...


Lu Yang 24Lu Yang 24
same here, we use process builder to change case owner to a dummy user, but it seems assignmnet rule fire 2nd time to change back original queue


Julie Zaretsky 6Julie Zaretsky 6
I did the following:

  1. Create an inactive case assignment rule called "Do Nothing"
  2. Make 1 rule entry. Criteria is Formula which simply says TRUE (so always true) and checked "Do Not Reassign Owner" for the assignment part
  3. In any apex code where you don't want Case Assignment Rules to fire, do this to specify the "Do Nothing" rule to your update:



AssignmentRule ar = [select Id from AssignmentRule where SobjectType  = 'Case' and Name = 'Do Nothing' limit 1];
Database.DMLOptions dmlOpts = new Database.DMLOptions();
dmlOpts.assignmentRuleHeader.assignmentRuleId = AR.id;

/* set your case owner and whatever else here */

database.update(MyCase, dmlOpts );


 


James (CloudAnswers)James (CloudAnswers)
Experiencing the same bug using the rest api upserts.  If you do a rest upsert to update an existing Case it will re-trigger assignment rules.  In our example, this is happening when posting json data to the rest api and not appending any extra headers for assignment.

The work-around we use:

Just add a first line to the assignment rules to not change the owner if it's not new:
User-added image

 


Kel Woodbury (SMB)Kel Woodbury (SMB)
I was doing some updates to a couple of hidden checkboxes on cases real quick in the developer console and was quite confused when the cases got assigned back into the queues.  That NOT(ISNEW()) trick for the first assignment rule is a handy workaround for the issue.  It just didn't make any sense to me why the cases were firing the assignment rules again since it should only ever be on a new record (and even then we have to fire them manually in an after insert trigger because Cases created by the Process Builder don't trigger the assignment rules in the first place).


Ben FalterBen Falter
How is this still an issue after 8 years?!? 
We have the same issue occurring when a Trigger on a custom object updates a field on Case. Even resolved cases are being run through assignment rules.

We fixed by refactoring assignment rules as formulas and adding ISNEW() to the criteria.


aostv apkaostv apk
Bug is fixed now! you can now use it without any issues and errors!
https://aostvapk.fun/


Lorenz AlexisLorenz Alexis
I also am encountering this. Is this fixed? What is the resolution?


ritu bansalritu bansal
Trigger and Workflow field update
Let’s say after sometime, requirement came to calculate and update field on Vehicle object. Considering timeline to deliver this requirement, team decided to choose Workflow field update over modifying existing trigger. Consider that workflow rule is written to execute every time when record is either created or updated.
Now, whenever any record of custom object “Vehicle__c” is updated or created, chances that trigger will execute will be “four times” because of sequence of execution.
When record is created or updated trigger will execute twice (before and after event) and after that workflow field update will cause trigger to execute again (before and after event).
Trigger, Workflow and Process builder field update
To make situation worst, if we write field update on same object “Vehicle” in Process builder also then trigger may execute “six times” instead of only two times kgtopg (https://kgtopg.in/" target="_blank)
 


want fallwant fall
Velocity Lean Diet is a breakthrough formula that allows you to get rid of excess fat fast and easily. It is a natural formula. Read our Velocity Lean Diet Review to find out the right solution. Replacing the food we eat allows us to still make fun and enjoyable recipes. https://arynunez.com/velocity-lean-diet-review/