I want to learn different ways how you guys handle incoming emails in Dynamics CRM.
How you make sure that everyone is responding to their emails?
Can we filter incoming emails to get the ones which are not yet
replied? On daily basis we are getting a lot of emails and we want
to have a filtered view where we can only see the emails which are
not yet replied yet.
How you deal with incoming emails which are sent to sales#
accounting# etc.
3A. How you distribute them among different users?
Assigning to them?
Forwarding to them?
3B. And how you make sure that they are replying to those emails?
I will appreciate if you I can learn from your experience on this subject
Use the existing Customer Service module which Microsoft has built for this purpose. Incoming emails create Case records, which are actionable items with associated statuses.
How you make sure that everyone is responding to their emails?
Set up workflows so that unassigned cases cause escalation of some sort (i.e. an email sent to a manager)
Can we filter incoming emails to get the ones which are not yet replied? On daily basis we are getting a lot of emails and we want to have a filtered view where we can only see the emails which are not yet replied yet.
Filter by Case status
How you deal with incoming emails which are sent to sales# accounting# etc.
- How you distribute them among different users?
You can set up routing logic so that cases are tagged with specific attributes, or assigned to specific users based on what address the originating email targeted.
Assigning to them?
This is out of the box case functionality
Forwarding to them?
Set up a workflow to send an email to the case owner or other user
And how you make sure that they are replying to those emails?
A simple option is to review the email history associated with the case. Automating this task is certainly possible but can get complicated.
You could add each email into a queue, and have users process emails out of the queue.
There is a setting to enable this on the entity configuration with the customisations area.
Emails when tracked or synchronised then appear within Dynamics within the queue.
Users then process the queue. This also caters for the scenario where emails do not need a reply - they can be removed from the queue. In this model, the emphasis switches from checking emails are replied to, to checking queues are cleared.
Reply email are linked back to the original email via the Parent Activity Id. So you could build a filter around this.
Create a queue for these to receive email.
The email address that you enter in the Incoming Email field receives all messages sent to the queue.
A) Users can pick items from the queue, a team leader can assign queue items to others, or use bespoke customisation or development to automatically route items.
B) As above.
Related
I'm using AWS SES to send emails to customers. I want to send an initial email to confirm an action they've made on my website, and then send subsequent emails to that same email address to notify of any subsequent activity on that initial action.
Different email clients appear to implement this behaviour differently, and I've read about the thread-index header here, but that doesn't cover all clients.
Is there a standard way to mark that an email belongs to the thread of a previously sent email?
Thanks
When adding the References Header to Emails, you can add message-ids of previously sent emails in order to create email threads.
Of course it's again a topic of the client to fulfill this feature, but it should be supported by major email clients.
Heres an old blogpost about that. (considering that email is also old, it should be fine ;) )
https://wesmorgan.blogspot.com/2012/07/understanding-email-headers-part-ii.html
In Email Queue, when I send queued campaign emails all emails are sent. I want it to send only the emails which are checked(selected checkboxes). Does any one know the way to do the same.
Thanks.
That's the default behavior, to modify it you'd check in /modules/EmailMan and ideally copy code/customization to the custom directory to try to stay as upgrade-safe as possible. Really, though, my experience with Campaign and Email customization is that there is heavy copy-paste from core files which are technically upgrade-safe but may not be upgrade-aware later on.
Also, the number of outgoing emails in a single blast can be controlled with Campaign Email Settings :
index.php?module=EmailMan&action=campaignconfig
On a more basic level though, why would you queue emails you don't want to send?
With regards an OMS, what is the best method to send a confirmation email? The 2 options I have so far are;
A script on the order page sends an email once the record is written to the database.
A scheduled task on the server, send the email, polling the database every-so-often to find new entries.
Which method do systems currently use?
For e-commerce websites, it might be better to think about the best user experience.
Given that, you would want to send the email as soon as the order is received so the user knows that they have purchased the item. The sooner it gets into their inbox, the sooner they will be happy that they have made their purchase.
I agree with Digbyswift that sending the confirmation email once the record is written to the database is the least scalable. But I would argue that if your system has gotten to the point that you are taking so many orders that your system cannot keep up, you have a wonderful problem on your hands that you now probably have resources to handle.
At PostageApp, we handle the emails of a few e-commerce websites, so perhaps you would benefit from an arrangement with an email service provider to off-load this task so that all of your resources can be spent on keeping your site up and your databases running.
Here are some great alternatives if PostageApp is not your style:
Sendgrid
Postmark
Mailjet
This is a question of scalability. Sending a confirmation email once the record is written to the database is the least scalable. The more orders that are taken , the more emails are sent potentially tying up resources.
A scheduled task is certainly better as emails can be queued up and can be sent in a separate process.
A further option which you could consider is using neither and delegating the responsibility of sending emails to a 3rd party dedicated emailing service, i.e. via an API. This is much better since your hosting does not have to consider the load and you can utilise any reporting offered by the 3rd party. Plus many services offer a free quota up to a certain threshold. This will allow you OMS and business to scale appropriately.
If you apply a message based architecture; you could just publish an order created message and have any number of subscribers respond to that event. You could create a listener that sends the email in house (bespoke option) or another listener that called the API of a 3rd party emailer to send the email on your behalf (as per #Digbyswift)
What I've always liked about this approach is
You can have any number of listeners live at any one time.
You can create a new listener and change how you send the email without needing to change/redeploy the OMS application itself.
You can take the listener(s) off line and stop / delay the sending of the email without losing any notifications or affecting the OMS itself.
Currently in our application admin of a company invite multiple users to system. Our design is:
take admin chosen separated email addresses, check user if exist and member of current company do nothing. if exist but not member of current company do some setup and add to company and send welcome email. if not not exist set user account add to company and send invitation email. But there is a hard roadblock. Admins want to invite up to 5000 emails. Because of currently we invite in web application and send email one by one (we have to, because of uniqueness and activation code) admin can't invite more than 20-30 emails at same time, because of timeout.
I thought to take email to another table and do operation with timer?
What is the best practice for this ?
Enviorenment
ASP.NET MVC2 on amazon-ec2 server. Also we have timer quartz.net
I come from a linux/PHP background but it seems to me your problem can be solved with a queue?
You basically get all the emails you need sending add them to the queue and have another process take a few emails off the head of the queue and send. Rise, repeat until queue is empty.
Since you are on EC2, have you taken a look at how Amazon SQS might be able to help? If you want a readymade component, I googled and found this email queue component for asp.net that seems to solve the exact problem you are having (although will cost you $)
I'm working on an application that will allow management to send registered users (opt-in) broadcast emails at regular intervals, or based on various other criteria. In any case, I'm curious as to whether I should send a separate email to each recipient or bcc all of them on a single message. Currently the email list would be about 1500 recipients, but it should scale all the way up to at least 25k without problems.
Thoughts? Am I getting into a range that I need to worry about being put on spam lists?
Yes, I've had spam list problem with mailing lists of that size, managing email lists for non-profits.
One wants to take extra precautions: make sure your email has SPF records, write a script to send the emails in batches, paced out over time. Definitely send them one one at a time, not as bcc, as direct mail has a better chance of arriving. Make it very easy to unsubscribe. Include people's subscribed email in the message sent -- often people have email forwarded to another account and then try to unsubscribe that account and get frustrated.
Even so, don't be surprised if you have to change your IP at some point.
You are getting into that range. This is the point where I would look to get a third party to send the email on my behalf. Let them worry about being marked as spammers, supply the bandwidth, etc.
I recently built an application with those same criteria. We do the emailing in-house, and send one email to each recipient.
Do use domain keys signing or be sure to use SPF records for your domain. We didn't do that at first, and were blacklisted by a number of different ISPs. Fortunately, it is fairly easy to get them to unblock you. Most will include an online form you can fill out or an email address you can use in the server bounce message.
Don't try to implement the actual email sending yourself. That's a huge waste of time. Either outsource the entire process to one of the many reputable vendors out there (Many organizations I deal with use Constant Contact, and it works well), or run a garden-variety mailing list server (e.g. Mailman) in-house.
Either way, take efforts to make it very easy to unsubscribe (good vendors have that covered), to authenticate that messages are from your company, and to show that your company is not spamming. Real mailing list server software supports all of these goals, by adding proper headers that identify the source very clearly and making unsubscription easy. For instance, Gmail will now offer to send unsubscribe requests in response to mailing list messages marked as 'spam', as has AOL for a long time.
Definitely set up SPF and DKIM if you can manage it.
Finally, whatever you do, make sure you keep logs of your subscriptions, so that if someone does accuse you of spamming, you can defend yourself.
The task is mostly uninteresting on a strictly technical level. You should worry about what happens when a recipient thinks that your list's content is spam and starts (a) complaining or (b) flagging the message as spam with one or more anti-spam service providers. Something like this is bound to happen with a list of the size you describe.
If you are prepared and have the time handle such cases, go for it, at least for a start. (Changing your mail server's IP address as Devin Ceartas suggests won't be of much use by the way.)
If you want to build your own thing, I have two pieces of advice:
Unsubscribing has to be easy, no more than one or two clicks. Using Mailman or any other mailing list manager that was intended for discussion mailing lists is asking for trouble.
BCCing the same message to 1500 (or 25k) recipients may take some load off your mail server, but it has one serious disadvantage: You won't be able to use VERP in order to determine if all addresses that have once been subscribed to your list are still valid. (Large mail providers tend to classify messages as spam if there are delivery attempts to many invalid addresses.)