30 day trial
In previous versions of MSCRM, users have been able to integrate their CRM data with e-mail hosted on Microsoft Exchange servers. This was done through the use of Forward Mailboxes. The method used to determine if incoming e-mail messages should be tracked or not was by matching a tracking token in the subject line of the e-mail. In addition, administrators had to install and configure the e-mail router service on the Exchange server hosting the Forward Mailbox.
MSCRM v4 allows you to continue to integrate your e-mail systems in the same way, but many new advancements in design enable users to create a richer and customized solutions for their unique situations and configurations. Here is a look at many of the new features and functionality of the MSCRM v4 e-mail integration story.
No more tracking tokens! The e-mail tracking token is used help the router decide if an incoming e-mail should be tracked in CRM or not, and if it is to be tracked it will ensure that the correct regarding object is set for the received e-mail activity. This option still exists in v4, however it is now optional. MSCRM v4 utilizes smart matching technology which renders the tracking token obsolete. Smart matching enables the e-mail router to process incoming e-mail to determine CRM relevance by comparing subject lines and party lists (user e-mail addresses in the to:, from:, cc: and bcc: lists) with e-mails already existing in CRM. The tracking token can be configured or enabled/disabled by a CRM system administrator via the System Settings dialog.
Monitor individual mailboxes. Previously, all incoming e-mail was monitored through the Forward or “Sink” mailbox. E-mail sent to CRM users and queues was forwarded as an attachment to a specified mailbox which the e-mail router monitored for e-mail processing. In v4, administrators have the ability to monitor individual mailboxes directly, or monitoring incoming e-mail through the Forward Mailbox or the Outlook client. This setting is specified in a dropdown list on the MSCRM user or Queue record form (E-Mail Router), and it is configured using the E-Mail Router Configuration Manager tool.
MSCRM v4 offers administrators the flexibility to configure users and queues in multiple methods in the same deployment. It is possible to configure some user/queue mailboxes to be monitored directly on one e-mail server while others are configured so the E-mail Router processes mail from a Forward Mailbox on a different e-mail server. Individual mailbox monitoring also provides the administrator the option to allow CRM users to enter their email credentials securely in their personal options.
New e-mail tracking options. CRM users also have the option to customize what types of e-mail messages the E-mail Router will track. These options include all incoming e-mail, mail in response to CRM e-mail, or incoming e-mail from CRM accounts, leads, or contacts. This functionality is available for queue records as well directly within the queue edit form.
Improved e-mail configuration management. MSCRM v4 now provides the ability to customize and configure the e-mail router service to meet all incoming and outgoing e-mail connectivity requirements via a Configuration Manager application. This UI-based tool allows an administrator to configure incoming and outgoing profiles, including connection types, direction, access credentials, connection ports, time outs and other connection details. Connections to CRM deployments can also be similarly configured. Based on the deployment selected, both incoming and outgoing e-mail profiles can be specified for selected users, queues, and forward mailbox.
Support for POP3. Until now, all e-mail monitoring and processing was only possible with mailboxes on Exchange servers. MSCRM v4 now offers administrators the flexibility to utilize POP3 mail for their user base. POP3 monitoring is configured through out-of-the-box settings in the E-mail Router Configuration Manager tool.
De-coupled Router Service. In v3 the E-mail Router had to be installed on the same Exchange server hosting the Forward Mailbox. In v4 we have removed this restriction allowing the administrator to install and run the service from any machine which can communicate with both the MSCRM server and the e-mail server. The router is effectively an intermediary connecting the two separate systems (CRM and e-mail) and this new design enables full functionality without the previous restrictions. All that is needed are the administrator credentials to connect to MSCRM and the credentials to communicate with the remote e-mail server.
Configurable SMTP connection for outgoing e-mail. In the previous CRM versions outgoing e-mail was delivered via the MSCRM platform using a remote or local SMTP server. In v4 this is easily configured via the E-mail Router Configuration Manager tool. Given the flexibility of the e-mail connector, it is now possible to define multiple outgoing SMTP server profiles. This is extremely useful for enterprise deployments where you may want users in one region to use one SMTP server and users in another region to use another SMTP server. As with the incoming profile configurations, all that is needed to properly connect to the SMTP server(s) are the proper login credentials.
Extensibility. The E-mail Router in MSCRM v4 provides the extensibility for external vendors to create their own custom e-mail providers which can be plugged into the MSCRM E-mail Router service. The custom providers can be written to perform deployment-specific tasks such as downloading RSS feeds and tracking them as e-mails, blocking e-mails with certain types of attachments, analyzing e-mail responses and uploading statistics, etc. The public class used for creating custom e-mail providers is Microsoft.Crm.Tools.Crm.EmailProvider.
Improved troubleshooting. In MSCRM v3, 7 performance counters were provided which tracked message processing such as the number of e-mail messages delivered, discarded, processed, etc. In MSCRM v4 the performance tracking capabilities have been improved by increasing the number of counters to 21. This will enable administrators to better track e-mail processing in order to manage overall e-mail router performance.
Within the E-mail Router Configuration Manager administrators have the ability to verify connectivity between the CRM system and the e-mail servers/mailboxes being configured via the Test Access feature. This process actually shows the administrator whether a connection can be expected to work as configured. In the case where a connection fails, useful error messages are surfaced to describe the problems in the connection to aid in troubleshooting.
Additional “What’s New” Changes. Along with the items already discussed, the following are noteworthy changes made to the MSCRM v4 E-mail integration story.
These items highlight the advancements made in the area of E-mail support in the latest release of MSCRM. Look for future blogs highlighting topics such as how to set up and configure e-mail for your MSCRM v4 deployment in an enterprise environment utilizing the Forward Mailbox monitoring functionality effectively for scale, using individual mailbox and MSCRM Outlook client monitoring with POP3 and/or Exchange providers and proper login credential management, and troubleshooting common problems along with suggested solutions.
For further information about Microsoft Dynamics CRM v4 e-mail configuration and usage, please visit the following resources:
Saying that the tracking token is 'obsolete' is a bit strong unless there is more to this intelligent tracking technology than stated. If there are numerous emails with the same subject and to/from people but from completely unrelated records, I don't see how the emails will track properly without a token. How many emails do we all get that say just CRM and/or re:CRM. Without a token, those will not get tracked to the proper regarding value, will they?
It many not be totally obsolete yet. But it's certainly getting close to it.
The tracking token is no longer required as part of e-mail tracking in MSCRM v4, so in that sense it is 'obsolete'. Users have the option to include it if they wish, but many users have asked for a way to remove it. As to the smart matching logic used to process incoming e-mail messages, an algorithm computes the 'likeness' of incoming messages compared to existing e-mail activities, and based on this will decide if it is a match and set the regarding object accordingly. If no match can be determined, the e-mail activity will be created with no regarding object set. Since the regarding object can be set on closed e-mail activities, the user can manually set this to its proper value as needed. In the case of multiple matches, the most recent CRM e-mail activity will be selected for matching and its regarding object will be copied to the new activity. This should happen rarely in actual practice.
Consider an example of a CRM user sends multiple e-mails to external contacts with the subject "your order". Each outgoing e-mail activity will have a different regarding object (contact A and contact B). If contact A replies directly, the subject will be "re: your order" and the party list matching will match it to the outgoing activity and set its regarding object appropriately. Contact B forwards the e-mail and drops the CRM user to the cc: line, so the incoming e-mail will be "fw: your order". Since the party list matches at least 2 parties and the subject still matches ("fw: " is ignored), the e-mail router will match this to the correct outgoing e-mail and set the proper regarding object. These work as expected Now suppose the CRM user sends another e-mail to contact A about a different order but has the same "your order" subject content. If the contact replies to the first "your order" e-mail now, the router will use the most recent e-mail activity to process in the incoming e-mail and match its regarding object. If the regarding objects are the same for both outgoing e-mail activities then there is no conflict since the same regarding object will be set on the new incoming message. In those rare instances where the e-mail is matched to the wrong regarding object (e.g. the order instead of the contact), the CRM user can modify the regarding object directly to match the correct thread.
What's the performance hit on the smart matching technology?
I am actually seeing that incoming status failure on one of our implementations, it looks very similar or exactly like that. Do you have any ideas as to what's causing this?
sorry but I don't quite know how to configure the email access type settings for incoming and outgoing mail to monitor users's mailboxes per the section headed above which I have copied below
"Monitor individual mailboxes. Previously, all incoming e-mail was monitored through the Forward or “Sink” mailbox. E-mail sent to CRM users and queues was forwarded as an attachment to a specified mailbox which the e-mail router monitored for e-mail processing. In v4, administrators have the ability to monitor individual mailboxes directly, or monitoring incoming e-mail through the Forward Mailbox or the Outlook client. This setting is specified in a dropdown list on the MSCRM user or Queue record form (E-Mail Router), and it is configured using the E-Mail Router Configuration Manager tool."
How do these access types allow an administrator to monitor a mailbox? Any more help would be most welcomed. Thanks
James - in the screenshot I included, the incoming status failure is due to the mailbox not being initialized in Exchange. Check to see that your mailbox is initialized properly.
Robin - the e-mail router does the actual monitoring and processing of incoming mail, but the administrator needs to set this up correctly. To enable the router to process a user's incoming mail directly (e.g. from the user's inbox), the option for "E-mail Router" must be selected in the user's CRM form. Within the E-mail Router Configuration Manager tool, an incoming profile must exist which includes the necessary access information for the router to be able to access the user's inbox, and this profile must be applied to that user. If the profile has Access Credentials set to "User Specified", then the user must enter their credentials in their personal options dialog within CRM. This would not be necessary if the router's incoming profile specifies "Other Specified" or "Local System Account" access credentials.
I hope this helps. Look for future posts describing the configuration and deployment options in greater detail.
A few days ago, David West posted about the new e-mail features in CRM 4.0 . For many of you, this list
Bueno, el mundillo entorno a Microsoft Dynamics CRM 4.0 ya empieza a ponerse frenético y es difícil mantenerse
I'm not clear on how to install the e-mail router on a server that isn't an Exchange server. In the "E-mail Router Configuration Profile" dialog box, what am I entering in the "server" field? Is this the OWA URL for the target Exchange server or something else?
Also, what credentials should I be using? should this be a domain user with full access to all forwarding mailboxes used by this profile?
We are running CRM 3.0 and can not send any mail directly from within a CRM shell (contact to SEND). Outlook is fine and tokens a CRM #. Tracking is fine. We are using SBS2003, Exchange 2003, seperate CRM App Server
Adam, if you're having a problem sending e-mail from CRM 3.0, you should contact our Product Support team and work with them to solve this issue. Thanks.
We are having a problem whit the email router. I configured my incoming method against my gmail/pop3 account for testing purpose. For outgoing method I use one of our internal smtp servers. Everything works great when I start the service and try the mail flow (in/out), but after some hours of email inactivity the router does not process anything. Even if I wait 1-2h nothing is being processed. When I then restart the service all of my messages get processed.
What is happening? Is there something I can do to prevent this? Note that I am using the default timesettings under the advance tab in the config-manager. I am the only user on this environment and I am not sending large attachments or anything.
"...the MSCRM v4 e-mail router is fully compatible with Exchange 2007."
What precisely does this mean ? Does this mean that the MSCRM v4 e-mail router totally removes the requirement for the CRM E Mail Router to be connected to a server that is running Exchange 2003 and that is part of an Exchange 2007 organization. That is _NO_ Exchange 2003 server is required. You can have just Exchange Server 2007 installations only in the organization !?!