This project is read-only.

Duplicate Cases from email reply's

Jul 23, 2008 at 1:58 AM

As others have said, this is a great contribution to the CRM community.

Anyway, I'm wokring on version 1.6 and email replies are generating new tickets.  Here is the scenario:

- Email comes in.
- CRM Queue Manager creates a case.
- Support staff get a notice of new case.
- Support staff open the original email and reply back to the person.  They also change the From address to the Queue.
- End user sends a reply back to the queue.
- The queue associates the email to the correct case (regarding field is set correctly).
- The next time CRM Queue Manager runs, it creates a new ticket from the email reply, and changes the regarding to the new Case.

I do not use tracking tockens or the ticket number in the subject line.

Any thoughts on what I'm doing wrong? 


Jul 26, 2008 at 9:12 AM
Hi Chris,

This is how we process new e-mail: "Get a list of all objects on queue X with object type code 4202 (email) with a regardingobjectid that is null (unassociated)". So if your e-mails are processed even if they are associated regardingobjectid should be null in your case. The token system might behave different when used with no tracking number. Has this always been a problem or can you see that it has started recently? All Windows services started on the CRM server?

I haven't used the new tracking algorithm in CRM 4.0 since I can't see how it can work so there might be a problem there that I'm unaware of.

Let me know how it goes.

Jul 30, 2008 at 12:06 AM
Hi Manso,

Thanks for the reply. I suspect there is a challenge somewhere with my setup, I'm just not sure where to find it.

I've tested both with version 1.5 and 1.6, I've tried different accounts (to make sure it's not a permission challenge), running as a service and manually, manually setting the Regarding field, but I get the same result.  For some reason, email replies get treated as new requests - even though the Regarding field is already tied to an existing case (not null).

The one exception:  if I put the Case number in the subject line and set the matchcaseticketnumber option to True.

The only other thing I could think of is, I've renamed "Cases" to "Tickets" in CRM (to be more aligned with our line of business).  Could that have anything to do with it?

Anything else jump out at you on what I'm doing wrong??


Jul 30, 2008 at 11:30 PM

Hi Chris,

It sounds like the E-Mail router hasn't associated the incoming e-mail with the case. If you stop the Queue Manager and wait for the incoming e-mail (the reply), is it then associated with the original case? It should work the same way as if you are using a tracking number but it's using subject+sender+recipient to figure out if it's associated to something (which I can't see how it can work). Does it work if you enable tracking number (for testing purposes)?

Renaming the entity simply changes the display name and shouldn't affect anything, the physical name is still incident which is what the web service layer is using.

I which I could be of more help. I suspect the e-mail router doesn't set the regardingobjectid attribute for the replies. Otherwise there's no way the e-mail would be processed by Queue Manager in the first place. If it's set, the query engine in CRM is broken ;-)

Let me know if you firgure something out.


Aug 3, 2008 at 11:55 PM

Hi Manso,

Again, thanks for your help - much appreciated.

Trouble is, the regardingobjectid is set when the email reply comes back from the end-user.  I can open the Case and see the email in the History.  But, when I run QueueManager, it treats it as a new mail message (and will create a new Case).

When I use version 1.4 everything works perfectly.   

Of course, I would like to use v1.6 for the more advanced features.

Any ideas?




Aug 4, 2008 at 10:14 AM
Sounds like the setting removerepliesfromqueue is set to true if it has changed between the versions. Or it's a bug that we're not aware of. removerepliesfromqueue was added in 1.5 in order to automatically remove e-mails from the queue which has already been assigned to a case (don't know why some people want to use it this way). Maybe this is causing the problem. Is it set to true?

Aug 5, 2008 at 8:14 AM

Hi Manso,

OK, that did it!  When I set the removerepliesfromqueue option to false, everything works in version 1.6.  That's probably the one setting I didn't try.

Now I can set the Ticket Origin when the Case is created.  Whoo-Hoo!  Life is good.