"In" Operator in CRM Workflows

Radoslavov

380

Like ( 0 )

Report

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 suport@contoso.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.

It took some months before we found the problem here and the reason some emails were skipped.

Explanation

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 support@contoso.com because it is only a queue, but if we have for email sales@contoso.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 someone@gmail.com 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 someone@gmail.com.

What if we have more than one record from a different entity in CRM with this email address?

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.

What can be the used case to have records with same email address?

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.

Workarounds

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).