Ask Search:
Evan DeckerEvan Decker 

Cases getting reassigned upon reopen

Hello. We're running into an issue where cases are being put into a closed status, then an email is being sent to or from the case causing it to be reopened, and upon this reopening the cases are being reassigned to the queue specified in the original assignment rule used for email-to-case. There are no workflows or triggers that would be causing this. Looking through the debug log, it appears this assignment rule is being applied again when the case is reopened. This is only happening with certain email-to-case setups, not all of them.

Has anyone ran into this before? Is this normal functionality? Thank you!
Best Answer chosen by Evan Decker
Jon TreskoJon Tresko
Yes, we'd be putting an additional condition in all assignment rules. This would require the case to be new in order for the assignment rule to fire. If it's not new, then the assignment rule does not fire.

In other words, if you have an assignment rule that's firing for Cases or Leads that it should not fire on, you need to find out what makes those records different and filter that value out of the assignment rule, so it does not consider those records for assignment.

I'm sure there's other filters that may help in this scenario, such as ISCHANGED(Status) or something like that...

You could also try adding something like CreatedDate = TODAY()

No matter what, there needs to be a condition in each assignment rule that can identify these records in question and ignore them.

You could also try having an assignment rule at the front that just looks for these specific re-opens and assigns it to the same owner...

All Answers

Sharif ShaalanSharif Shaalan
Hi Evan, you should add ISNEW to the original rules, that should stop them from firing on re open
Jon TreskoJon Tresko
Also, NOT(ISCHANGED(Status) may help
Bill GreenhawBill Greenhaw
Evan...you sure no one built a trigger to reopen the case when an email comes in?
Evan DeckerEvan Decker
Thanks everyone.

Sharif and Jon - I'll give those a try next week, I think the ISNEW function might do it.
Bill - not 100% sure, but we can't find anything that is apparent.
Evan DeckerEvan Decker
Hi guys, unfortunately neither of the two functions suggested worked. Does that mean there has to be a trigger or something firing when these cases are reopened?
Jon TreskoJon Tresko
Actually, I may have misunderstood a bit. Just so I understand...

Are you trying to figure out why the Cases are being re-opened and trying to prevent the e-mail being sent so the case remains closed?

Are is the case supposed to be re-opened and you're trying to use a different assignment rule? Please help me understand exactly what you are trying to achieve or prevent. Thanks!
Evan DeckerEvan Decker
Hi Jon, I do want the emails to be attached to the case, and the reopening of them is fine. The issue we're having are the cases are getting reassigned when the are being reopened (the assignment rule is firing again). I would like to prevent this from happening so the case stays in the name of whoever closed it in the first place. Does that help?
Jon TreskoJon Tresko
Yes it does. So the E-mail is sounds like a Case Closed confirmation e-mail...?

If they are truly closed, I would think they should also stay closed, as it could totally screw up your reporting and productivity if a bunch of open cases are showing up that should really be closed. If the e-mails are coming from customers and you would like them to be re-opened because a new e-mail might mean the case should still be open, but we want to ensure the same rep has it, we'll try to address assignment rules.

Please let me know which one and if you just want to focus on Assignment rules, please post a screenshot of your assignment rules page. (You can post to chatter and tag me in the post) or use www.awesomescreenshot.com
Evan DeckerEvan Decker
In my case the latter of the two is true - emails are coming from the customers, reopening the cases, but I need to ensure the case stays in the same rep's name instead of getting assigned back to the queue. I'll post a screenshot of our assignment rules in a second here.
Jon TreskoJon Tresko
Ya, so you'll just need to make sure the assignment rule filters these out.  So In every assignment rule, you'll need to make sure it considers your existing filter AND that it's not re-opened... For Example:

AND( ISNEW() = True, ISPICKVAL(Origin, "Non-Integrated Services"))

or

AND( ISCHANGED(Status) = False, ISPICKVAL(Origin, "Non-Integrated Services"))
Evan DeckerEvan Decker
Hi Jon, I just tried both formulas and neither worked. One other thing to consider (not sure if this matters or not) - the default case owner is the same queue (Non-Integrated Services). Do you think that might be playing into this?
Jon TreskoJon Tresko
Did you add it to every single assignment rule?

You could try changing it to AND( ISNEW(), ISPICKVAL(Origin, "Non-Integrated Services"))

However, it would have to be on ALL assignment rules, to make sure all scenarios get picked up. I think in some cases you'll have to changed from criteria to formula to evaluate, so it's a big change to test.
Evan DeckerEvan Decker
Are you saying the ISNEW() function needs to be added to all assignment rules? I don't understand how that would help.
Jon TreskoJon Tresko
Yes, we'd be putting an additional condition in all assignment rules. This would require the case to be new in order for the assignment rule to fire. If it's not new, then the assignment rule does not fire.

In other words, if you have an assignment rule that's firing for Cases or Leads that it should not fire on, you need to find out what makes those records different and filter that value out of the assignment rule, so it does not consider those records for assignment.

I'm sure there's other filters that may help in this scenario, such as ISCHANGED(Status) or something like that...

You could also try adding something like CreatedDate = TODAY()

No matter what, there needs to be a condition in each assignment rule that can identify these records in question and ignore them.

You could also try having an assignment rule at the front that just looks for these specific re-opens and assigns it to the same owner...
This was selected as the best answer
Evan DeckerEvan Decker
Thanks for all of your help Jon. I'm going to try a workaround using a workflow rule. Your efforts are deserving of a best answer!
Jon TreskoJon Tresko
Not a bad idea... You could trigger a WF rule to flag all cases that have been assigned via assignment rule, the add that flag to the assignment rules so they ignore records already assigned. lmk what ends up working out for ya...
David EckbladDavid Eckblad

Hi, I actually took over for Evan.

The issue is due to the "Default Case Owner" setting under Customize -> Cases -> Support Settings.

If you set the original assignment rule to include ISNEW(), it'll skip that rule on reopen, not hit any other rule, then default to... BAM! the same queue in question!

So, to alleviate this. Leave the ISNEW() on your first assignment rule.

ISNEW()
&&
ISPICKVAL(Origin, "Default Queue Name")

Then, you have to create a final assignment rule where you check the "Do Not Reassign Owner" box only if the case is not new. So, the filter logic would be like:
 

!ISNEW() 
&& 
ISPICKVAL(Origin, "Default Queue Name")
Note the only difference is the "!" to negate the ISNEW().

 

Evan DeckerEvan Decker
Hi Dave - were you able to resolve the issue then?
David EckbladDavid Eckblad

Yes and no. I've redefined the problem.

http://salesforce.stackexchange.com/questions/47156/on-demand-email-to-case-not-running-assignment-rules-on-emails-with-reffooref?noredirect=1#comment61638_47156

https://success.salesforce.com/answers?id=90630000000i5kNAAQ