by: Ritchey Hazeu & Robin Schaareman
1. Setup Mailboxes
Since we were going to connect multiple mailboxes to CRM there were several options on how to do that. We chose for the option to make an Exchange Online Rule to send all incoming e-mails to one leading e-mailbox. This mailbox will receive all the e-mails of all the connected (functional) mailboxes and this leading mailbox is connected to Dynamics 365. We choose to go for one leading mailbox because you only need to setup your configurations once, instead of a unique configuration for every mailbox.
1.1 How to set up a mailbox in Dynamics 365
When connecting the mailbox make sure you got Exchange Online admin rights or Office 365 admin rights (or connect with someone who got them instead).
When creating the mailbox make sure you use the below options:
When you’re done creating the mailbox, Save, click on Approve email, after approval click on Test & Enable mailbox. The status should go to Succeeded….
If you’re forwarding a mailbox to the leading mailbox with a lot of historical data you also got the possibility to choose for a particular time to sync. This can be found in the Email Server Profile, advanced tab (sorry for the Dutch language😉):
Don’t forget to create mailboxes for outgoing email traffic. Follow the same steps as above but only select Email router for outgoing email. Users will be able to select this outgoing mailbox (connected to a queue) when creating emails.
2.ARCUR and Routing rules
The new ARCUR is being managed by a Power Automate flow (actually 2 flows) which you can create from the ARCUR data record. Within this Flow you can execute all sorts of conditions to convert the email to a case and if this is not possible place the email in the right queue.
When a case record is created from the ARCUR flow we wanted to let the routing rules decide which queue it should enter. Therefore, we placed the email addresses (To and CC) in the e-mail field on the case so the Routing rule can pick it up and route it accordingly.
One of the most important things we’ve implemented was to extract the CC email from the activity party entity related to the email record, since the out of the box activity party was not working properly in Flow.
It should look similar to the following:
After that you can place the Cc email string variable in the creation of the Case, together with the To field. The routing rule will do it’s work accordingly.
3.Lessons Learned
Since we went live, at first with a pilot of 1 e-mailbox and later on we connected more e-mailboxes, we faced some issues/situations which we need to monitor more closely or improve on next time we connect an e-mailbox.
3.1 Tracked
to Dynamics (undeliverable)
We noticed that no
new e-mails were coming into Dynamics 365 anymore. We checked several things
and saw that our “dummy” e-mailbox was receiving all the e-mails of the
connected e-mailboxes but they were not showing up in Dynamics 365 anymore. All
e-mails that were in Dynamics 365 had a label “Tracked to Dynamics 365” and all
e-mails that were not tracked to Dynamics 365 had a label called “Tracked to
Dynamics 365 (Undeliverable)”. After quite some research on several settings we
created a ticket at Microsoft because everything was setup correctly and
nothing was changed since the error occurred.
After a few calls with the Microsoft team we found out that is was a known issue on their side which had something to do with the ARCUR flow. We did not check the ARCUR flow since we thought that all e-mails should be in Dynamics 365 first for ARCUR to do something with it. Unfortunately we were wrong and ARCUR can influence the behavior of emails being tracked, or not. Simple solution/work-around for now was to disable ARCUR and enable it right away. New e-mails were coming in the system again and all seems fine.
Why this occurred has not been clarified by Microsoft yet since they still work on this issue that will prevent this*. It took some time for us to figure out that turning ARCUR off and on again would do the trick, all the e-mails that were send to the ‘’dummy’’ mailbox were not processed to Dynamics 365. To trigger this again we needed to add a field to the Mailboxes field. The field is called “Process Email Received After”. Once this field was added tot the form we could change the date to the past and it will trigger the process to track e-mails to Dynamics 365 again.
*we will try to update this blogpost if we have more information about the error in the ARCUR flow.
3.2 Monitoring
Once we had the error that e-mails were not being processed we needed to make sure that the next time this happens we needed to be informed sooner. To be faster we need to create some monitoring that will check on the categories in Outlook, once a Undeliverable category is assigned we need a signal so we can fix it right away.
The other monitoring part is maybe an overkill but it will help to grow trust in the system. Check the number of e-mails being received on the e-mailbox vs the “dummy” e-mailbox vs Dynamics 365. These numbers should add up. Once this is not the case it needs investigation on what happened so you can act accordingly.
3.3 Delay
ARCUR
Dependent on
how your ARCUR flow is setup you need some delays build in to make sure an
E-mail is attached to the correct Queue. In essence our ARCUR is doing the
following:
- Check if the e-mail can be converted to a case, if yes a Case is created
- If the e-mail can’t be converted to a case the e-mail is attached to a general queue
Unfortunately, this interfered with the queues that were setup. The queues were setup that if an e-mail from Mailbox X was coming into Dynamics 365 it was going to be assigned to the queue of Mailbox X as well. We found out that some of the e-mails were in the queue of Mailbox X and some of the e-mails were in the general queue. This happened because sometimes the ARCUR was faster than the Queue itself and attached the e-mail to the general queue. In other scenario’s the queue was faster which resulted in the e-mail being attached to the queue of Mailbox X and ARCUR generating an error the there was already a queue item of that e-mail. The general queue is for e-mails that could not be attached to their correct e-mailbox queue, for example an e-mail that had the attached e-mailbox in the CC instead of the TO.
To prevent this, we made a wait condition in the ARCUR flow so it could check if the e-mail was already attached to a queue. If this was not the case ARCUR can attach the e-mail in the general queue.
3.4 Duplicate e-mail
We’ve faced a scenario where emails entered CRM accordingly, got converted to a Case, but for a particular mailbox the emails were not routed to the right queue. The Routing rules were setup accordingly but after some investigation we saw a contact person record created with the same email address as the mailbox. For CRM it’s 2 duplicate records, one queue and one contact person record with the same email. For CRM it’s impossible to decide where to route it to. So our advice is, inform users to NOT create contact persons with the same email as their own mailbox.
4.Conclusion
Eventually we managed to successfully setup Case management into Dynamics 365. We encountered numerous hick-ups during the implementation which costs us a lot of time. Hopefully you can use our blogpost in your advantage to save some precious time 😊