This project is read-only.

Feature Request: don't convert to cases - leave as email for Sales Queues

Jan 26, 2010 at 9:43 PM

We've got CRM Queue Manager gpoing great (thanks HEAPS) and I really love the web verification system.

What I'd like to do, is create another queue - "Sales" with a "Sale TEMP" queue and use the verify process within CRM Queue Manager to handle the queue.

The only modification I'd like, is for CRM Queue Manager NOT to convert a verified email into a case, just leave it as an email. Do everything else it does, just don't convert it to a case. Thus, we can then manually convert it to a lead or case or whatever we think is most approriate foir this particular email.

So, the config file might have a new option:

ConvertToCase="false" (if not present, then assume a value of "true")

And, thus, we get the chance to convert it.

This would make managing a queue such as or really nice. The verify system is brilliant at stopping spam and I really like the templates for answering emails etc.

Since we're not converting it to a case, you would need to make the "ticket" ID a CRM tracking token instead too...


Jan 27, 2010 at 11:20 AM
This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.
Jan 27, 2010 at 11:24 AM

Great suggestion. Will implement this. Can you please expand on the last ticket ID sentence?

Feb 7, 2010 at 12:35 AM

I've been asked to expand on the "ticket" ID last sentence.

I'm fairly new at CRM, so I might be saying something silly, but in the templates, I see things like "{ticketnumber}". This ticketnumber is the CRM case ID, but in this case, we would not have case numbers, just the standard CRM tracking token because with my proposed modification this queue would not automatically be converted to a case.

So, that what I mean, is how do we make the temples use the the CRM tracking token and not a CRM case number, because you are NOT in this case converting anything to cases?

As I say, I might have this all wrong and the ticketnumer will naturally be the CRM tracking token because it's not a case, but I just don't know that...

Feb 7, 2010 at 7:48 PM

I see what you mean. Are you using traking tokens today (the number in the subject line) or CRM 4.0's tokenless tracking? The tracking system will kick in whenever you send an e-mail via CRM which is what the case creation e-mail can do. But if we don't create a case the auto-reply will be quite useless.

Feb 7, 2010 at 8:49 PM
Edited Feb 7, 2010 at 9:01 PM

Yes, we are using CRM's tracking tokens.

The auto reply will still be very useful.

  • It will allow us to do the verify the user thing as an anti spam measure.
  • The email once verified, will not be a case but be available to be changed to a lead, case or opportunity as we see fit.
  • It will allow us to send an auto reply from an unattended mailbox with text of our choosing, such as:

mail from:

mail to:

subject: Re: "the subject line.." - auto reply

Body: Thanks for your email. Our sales team will review your email and get back to you shortly. If you need to call us, ring us on 123 456 789. Regards, Sales Team.


It's easy to have a different set of email templates to send for these queues that don't convert to cases. In these templates, we would not reference any ticket numbers because as you point out, they won't exist!


Lastly, just an add on thought. It might pay to have THREE CRM queues.

  • Sales
  • Sales inbound
  • Sales pending verify

New messages would come into "Sales inbound". CRM QueueManager would pickup from "Sales inbound" and if verification was required, move to "Sales pending verify" (and send emails, etc). If verification was not required, then move the messages to "Sales". Once verified, the message would move from "Sales pending verify" to "Sales".

In fact, that's quite a good idea for ordinary queues to cases too. I notice that if you have a Gadget or you regularly check the main queue, (in my example above, the queue called "Sales", you see messages arrive that CRM Queue manager has not dealth with yet. It would be better to "hide" these in another queue until fully processed.


Feb 15, 2010 at 11:31 PM

The problem is that the verfication process creates a contact today if the sender doesn't exist. We don't deal with leads at all since it's not a valid target entity for cases. Process is

1. Does a contact exist with the e-mail address?
2. Does an account exist with e-mail address?
3. If not, send out a verification e-mail and create the contact. <-- spam prevention
4. Carry on as normal

This would mean a lot of rewrite I believe to skip contact creation and/or handle leads. Sorry, I see your point but it would cause too much changes to the flow of the application. I'll have a look at it more in depth when we make next round of changes but it feels like we're stretching the functionality a bit creating a generic verification process. Also, it wouldn't take long for someone with basic .NET knownledge to modify the verification process to fit your needs.