This project is read-only.

Strange behaviour with the setting removerepliesfromqueue

Dec 10, 2008 at 3:26 PM

Hi Manso,

i noticed strange behavior with the setting removerepliesfromqueue.
My CRM system is set up to use tokens. Queue is set up to convert all incoming emails to email activities.

I send email to support queue. I manually run QM and it converts email to case.
I send another email to queue and it has the same subject as previous. CRM system receives email and sets email regarding field with the previous case. I would prefer, that CRM would not do this smart tagging, because it is very common situation, when customers reports problem with the same subject like "problem".

When I run QM with removerepliesfromqueue = "false" - nothing happens, the email stays in the queue as email.
When I run QM with removerepliesfromqueue = "true" - QM converts email to new case, changes regarding field with new case and removes email from queue.

I consider this as not a bug
J, but very useful feature which allows getting work around to CRM smart tagging problem.

Dec 11, 2008 at 12:38 PM

Hi there,

I had a similar discussion some time ago:

You mention you are using tokens which would, afaik, disable the CRM "smart" tokenless tracking. There might be a problem with the removerepliesfromqueue setting but I can't figure out what. Another discussion which implies something is incorrect:

Do you have more information that might help us nail this down after you've read these two discussions?


Dec 11, 2008 at 1:27 PM
Edited Dec 11, 2008 at 8:50 PM
here my points:

using tokens do not disable smart matching. So CRM could set regarding field of the email in both way - using token or using smart matching. QM setting removerepliesfromqueue acts different depending on how regarding field was set.I will try to look at the records in database - maybe there are some differences.

if you will have time - you can read about smart matching in CRM 4.0 here:

I did some testing:

CRM either using smart matching or token sets regarding object in the same way.
After I run QM in cmd, i see, that QM retrieves 2 emails, creates only one case, deletes email from queue from which case was created.
Dec 12, 2008 at 9:17 AM
Ok, this is how QM works.

If removerepliesfromqueue is false then QM retrieves all e-mail activities in the specified queue that has an empty regarding field. This is because we are only interested in e-mail activities that hasn't already been related to a case. For each e-mail a new case is created and the e-mail is removed from the queue.

However, when setting removerepliesfromqueue to true we need to retrieve all e-mail from the queue. When looping through the e-mails we check whether the regardingobjectid is set to a value. If it is we, detach the e-mail from the queue and check the next e-mail. New cases are created for unrelated e-mail.

What we're not doing here is check the type it's related to so it could be related to an e-mail, a case, a contact etc. Is this causing the problem perhaps?

Dec 12, 2008 at 12:06 PM
Edited Dec 12, 2008 at 4:16 PM
You are correct about retrieving emails, but something is in the looping process.
Email with the token is not removed from the queue. From the email without token, new case is created, even regarding field is filled, after case creation, email is populated with the new case in regarding field.

Both emails are related to the case.
From log I see, that email with token is retrieved and thats all. Email wihout token is retrieved, then contact is retrieved. We need to look what we have between retrieve of email and retrieve of contact.

I found my mistake, it is not related to tokens. Because I setted up QM, that it sends case creation email from CRM , but is also has case number also.
If I reply with token but without case number, QM creates new case despite email has regarding field filled.

Emails with case numbers inside subject are not removed from queue.

What I saw in the code when you create case, then removing from queue, you use detach from all queues, but after retrieving emails with regarding field filled, your use detach only from specific queue.
Dec 20, 2008 at 11:26 AM
What is matchcaseticketnumber set to? This determines whether to resolve e-mails with case ticket number in the subject line. This would otherwise generate a new case).

I can't figure out why we remove from one queue only in one place and not the other. When an incoming e-mail is processed by the router a queueitem is created in the personal WIP (work in progress) queue for the owner and in the queue with the resolved e-mail address. Once a case is created all queue items are removed. For some reason the same logic is not applied to the logic behind removerepliesfromqueue. This might be a bug but shouldn't cause a problem for you.

I couldn't follow you all the way in your reply. Do you still have a problem or was it the ticket number logic that was causing a problem?