I am restarting my developer newsletter, blog. What would you like to know how to do? Once, I have some content, I'll post how to subscribe.
I am restarting my developer newsletter, blog. What would you like to know how to do? Once, I have some content, I'll post how to subscribe.
I would like to have a way to prioritize the processing of inbound email.
I have about 20 different inbound-email records, each linked to a separate mailbox.
The scheduler always restarts in the same order, by ID of all things, and some really low-priority high-traffic queues happen to have an ID that puts them at the top of the list.
Sometimes this causes the scheduler to loop through the top 5 out of 20 (especially when bots start spamming us) restarting at the top every time again and again and not getting to the others in a timely fashion, which is not good for urgent cases (SLAs come into play) whose inbound email happened to get an ID that puts them at the bottom of the list.
My only solution right now is to make those low-priority lists inactive for the day, and then active at night... all manual work.
Should we be using email the way we do? Probably not. But even ignoring the poor business-model, it would be nice to be able to set priorities or have the scheduler continue from where it left off and not restart from the top.
Thanks!
FrancescaS
P.S. you asked for it ;)
Can you explain your use case for emails? We use Riva; have you looked into this or Sugar Connect?
This is probably an unusual scenario - so just keep it at the end of your list ;) I am sure there are much more useful things to address in your blog that would have a wider audience.
--- but here is the scenario:
We have:
info@ourdomain.com, which create cases assigned to CS USA team,
info-europe@ourdomain.com which get assigned to our CS Europe Team,
tech_support@ourdomain.com, for cases to our TS Team...
but also some internal email addresses that people bcc or forward to in order to log things against Sugar records that do not create cases, like interactions@ourdomain.com
(add a dozen more addresses to these examples and you have my setups).
All these are actual inbound_email records that map to mailboxes on our mail-server that Sugar reads.
When the Check Inbound Email scheduler runs it reads the mailboxes in order of ID:
001 interactions@
002 info-europe@
003 info@
004 tech_support@
interactions@... is the first being read by ID.
The scheduler reads that first and may take more than a minute or two to get through all the emails
(the emails are being processed to make sure that forwards are being logged with the correct to/from so that if I send a forward in interactions@ that is a message that was from you to me, it's logged that way and not as from me to interactions@ and parse for details to classify the messages and more)
So scheduler starts, reads 001 - interactions, does not get through all the emails
Next run starts, reads 001 - interactions again and continues... may no get through all the emails
...emails keep coming in to 001... scheduler starts from 001 every time and never gets to that urgent tech support 004 message that sits there for 20mins waiting to be read.
I have to set 001 to inactive so the scheduler gets to read what's been waiting in 002, 003, 004 and when things calm down (usually at night) I have to put 001 to active again so it can be processed.
But I have to keep an eye on the size of the inboxes in the mail server to know when to pause processing of 001.
In that example I want to prioritize 004-tech_support over 001-interactions without having to manipulate the ID of the inbound_email record to put it first in the list.
Does that example help?
Adding more products is not an option for us at this time.
Are there better ways of doing things, such as using a Case portal instead of email, sure. But that has not been an option on Pro and I have not had the bandwidth to create my own portal - yet.
Thanks,
Francesca
This is probably an unusual scenario - so just keep it at the end of your list ;) I am sure there are much more useful things to address in your blog that would have a wider audience.
--- but here is the scenario:
We have:
info@ourdomain.com, which create cases assigned to CS USA team,
info-europe@ourdomain.com which get assigned to our CS Europe Team,
tech_support@ourdomain.com, for cases to our TS Team...
but also some internal email addresses that people bcc or forward to in order to log things against Sugar records that do not create cases, like interactions@ourdomain.com
(add a dozen more addresses to these examples and you have my setups).
All these are actual inbound_email records that map to mailboxes on our mail-server that Sugar reads.
When the Check Inbound Email scheduler runs it reads the mailboxes in order of ID:
001 interactions@
002 info-europe@
003 info@
004 tech_support@
interactions@... is the first being read by ID.
The scheduler reads that first and may take more than a minute or two to get through all the emails
(the emails are being processed to make sure that forwards are being logged with the correct to/from so that if I send a forward in interactions@ that is a message that was from you to me, it's logged that way and not as from me to interactions@ and parse for details to classify the messages and more)
So scheduler starts, reads 001 - interactions, does not get through all the emails
Next run starts, reads 001 - interactions again and continues... may no get through all the emails
...emails keep coming in to 001... scheduler starts from 001 every time and never gets to that urgent tech support 004 message that sits there for 20mins waiting to be read.
I have to set 001 to inactive so the scheduler gets to read what's been waiting in 002, 003, 004 and when things calm down (usually at night) I have to put 001 to active again so it can be processed.
But I have to keep an eye on the size of the inboxes in the mail server to know when to pause processing of 001.
In that example I want to prioritize 004-tech_support over 001-interactions without having to manipulate the ID of the inbound_email record to put it first in the list.
Does that example help?
Adding more products is not an option for us at this time.
Are there better ways of doing things, such as using a Case portal instead of email, sure. But that has not been an option on Pro and I have not had the bandwidth to create my own portal - yet.
Thanks,
Francesca
Rather than resorting to modifying the id of the inbox record have you looked at creating a custom version of the "pollMonitoredInboxes" function to use? The query that collects the inbox records to check currently does so without any ORDER BY. I would be investigating adding a new field to the InboundEmail module called Priority which is numeric and setting these to put the inboxes in priority order for reading. Then simply adding the relevant ORDER BY to the query that collects them in my custom function.
This might be overly simplistic for your issue and it is slightly upgrade unsafe in that you need to manually adjust for future "enhancements" to the function but might be worth looking at if you haven't already. It has the benefit that you can easily adjust the priorities of your list of inboxes in the UI as well (good luck in remembering how to adjust the Smarty templates that the bwc modules still use here!!!).
If you have looked at it already and ruled it out then I'd be interested to know as the above is just my ramblings on first thinking about your issue. I have not tried anything to see what would happen :)
Thanks,
JH.