The views and opinions expressed in this blog are those solely of the author(s) and do not necessarily reflect Microsoft’s current policy, position, or branding. For official announcements and guidance on Dynamics 365 apps and services, please visit the Microsoft Dynamics 365 Blog.
See the Problem Solver of the Month for DecemberCongratulations to Ievgen Miroshnikov for be selected in a random drawing on Jan. 2 for in our monthly Dynamics 365 Community Problem Solver Sweepstakes.
Read aboug Ievgen | Learn how to enter
2019 release wave 2 Discover the latest updates and new features to Dynamics 365 planned through March 2020
Release overview guides and videos Release Plan | Preview 2020 Release Wave 1 Timeline
Ace your Dynamics 365 deployment with packaged services delivered by expert consultants. | Explore service offerings
Connect with the ISV success team on the latest roadmap, developer tool for AppSource certification, and ISV community engagements | ISV self-service portal
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Program | Finance TechTalks | Customer Engagement TechTalks | Upcoming TechTalks
Today I decided to share this not much as a Tip but rather as a brief explanation of the architecture of CRM and how “In” operator works in particular. Before that a little bit of context to understand the scenario and when to expect similar behavior. Recently, I had an issue where some of the emails sent to our company's support were not converted into cases. Basically the flow is quite simple, someone sends an email to email@example.com, this triggers a workflow to create a case inside dynamics CRM.
Now, some of you might ask "why don't you use care creation rule in CRM as an option?", the answer is that even dough the Out of the Box Case Creation rule option in CRM is good, there are some more things that we are checking before we create the case.
Anyway, back to the subject, in step 4 in our WF, we are checking if the email is sent to certain CRM queues (this can be Support, Sales, Licensing, etc.), and then it does other things (no need to bore you to death). Important to repeat CRM QUEUES.
What was strange dough, was that on a daily basis even dough the WF conditions were met and the support or sales email was in To of the emails, there ware some amount of emails that were skipped by the workflow and it went to the end of it with Success.
This is how the process visually looks like from behind.
You see, the problem here is that using the “In” operator in a condition where the left-hand side is a PartyList (like the Email.To property) is only supported when the Party List is expected to have a single value. The In condition evaluation only looks at the first element on the left-hand side (and always has). This works for emails send for example to firstname.lastname@example.org because it is only a queue, but if we have for email email@example.com a queue, account, or contact, or lead, or any other entity in CRM the same email address, this is mapped to 3 different parties (a queue, a contact, etc.)
However, if we have in To or CC field, let's say firstname.lastname@example.org which presence in CRM as Account and or Contact (or other type of record with this email address) and then Support@contoso.com (assuming that the customer put the first one for references to the communication), the WF will skip that particular email because, as I mentioned previously "The In condition evaluation only looks at the first element on the left-hand side (and always has). " in our case this is the email@example.com.
Another thing worth to mention here is that starting to pick the first item on the left-hand side, CRM will also filter them first by Alphabetic Order, and then by specific Entity Type order Lead, Account, Contact, although I thought I will order them by ObjectTypeCode as Account is 1, Contact is 2 and Lead is 4.
People often put other people in communication when writing emails to support. Some of these people might already be created as CRM records in your organization.
Usually, if the user puts in TO field only the support queue and all other people in CC, the workflow will work and the case will be created because the only element on the left-hand side now is our Support Queue.
But you can't really tell your customers "you need to put in TO only the support email and everyone else separate in CC or BCC.
There is an easy workarounds to handle this.... I can call it inconvenience, since it is not really an issue with the system, but the way it works.
Since we know that first the party members are ordered by alphabetic we can rename the queues to always be on top of the list. That way even if you have 10 records in To or Cc along with the support/sales queue, the first one on the left will always be your queue, which will create a case or do some other actions based on your WF logic. Keep in mind that symbols are above numbers (in case you name you queues 1support, 1sales, or whatever).
What I don't like in this workaround is that the display name will be populated to the end-user as well when typing your email address.
Another good workaround will be not to use "In" operator, but something like contains or begins with
.....but unfortunately, you can't use any other such this is the only option.
Hopefully one day this will come in help for some of you.
Link to the original LinkedIn post: https://www.linkedin.com/pulse/operator-crm-workflows-kiril-radoslavov/?published=t
Business Applications communities