Having implemented the workflow described by Jagan here to take an incoming e-mail and convert it automatically to a case, it became clear that some custom code would be need to solve the following problems:
- Using the workflow designer you cannot map the “from” field of an “email” entity to the “customer” field of an “incident” entity. If you think about it this makes perfect sense since the “from” field type is a PartyList (which is an array of Lookup types), whereas the “customer” field type is a Customer (which is just a single Lookup type).
- There’s no way to tell if the “from” field of an “email” entity is recognised as a known “account”, “contact”, “lead”, “user” or “queue” (the five entity types that can send/receive e-mails in Microsoft CRM). This means there is no way for you to create a new customer record automatically (if no record exists) when the e-mail is tracked. This is important for organisations who handle e-mail from potentially unknown customers, where no account, contact or lead record exists and the only unique identifier is the customer e-mail address.
- Take an email Lookup type as the input parameter.
- Call the CRM web service and retrieve the “from” attribute of the email.
- Although the “from” attribute field type is a PartyList and can, in theory, have multiple senders, in practice an email will have only a single sender. So we are just interested in the first party in the array of parties
- Determine if the party is an “account”, “contact”, “lead”, “user” or “queue” entity.
- Return the appropriate entity Lookup type as an output property. Because CRM only supports a single entity type per lookup property, using the CrmReferenceTarget attribute, we have to implement five different output properties, one for each “account”, “contact”, “lead”, “user” and “queue” entity type.
Following the SDK documentation for creating a custom workflow activity, my first job was to build the basic class, inherited from the workflow SequenceActivity base class, and override the execute method.
Simply compiling this class and registering the workflow assembly with Microsoft CRM, enables this as a new activity in the CRM workflow editor.
Next, I needed to pass an email as an input parameters to the activity. Again, following the SDK documentation for creating workflow dependency properties, this was pretty straightforward.
Compiling and registering the assembly exposes the input parameters to the CRM workflow editor.
In order to determine if the e-mail sender is already a recognised entity within CRM, I had to create five different output parameters, one for each of the possible entity types that could be a sender.
Again, compiling and registering the assembly exposes these output parameter to the CRM workflow editor, and in this case they are visible in the create case form.
Finally, I had to write the code to call the CRM web service, retrieve the “from” attribute of the “e-mail” entity we are interested in and obtain the lookup type of the sender (if one exists)
Now, I’m not going to delve into the code itself, but I stripped out any error handling, logging etc to leave just the key functionality, so hopefully it is pretty self explanatory.
The final piece of the puzzle is to build the workflow itself. In this example I have constructed a very simple example which works as follows:
- Call the “Get Sender” activity and pass the e-mail as the input parameter
- Test the output parameters for Null data (i.e the sender is not recognised). This can be tested for by using the “Does Not Contain Data” property of each output parameter.
- If one of the output properties does contain data, then create a new case and set the customer field to be the sender of the e-mail.
This workflow can be seen in the series of screenshots below.
Here we are testing each of the output parameters of the custom workflow activity for Null data.
Here we are mapping the outputs of the custom workflow activity to the “Customer” field of a new case.
As you can see, just a little bit of code solves this issue. In addition, we can now add a couple of additional workflow steps to create an “Unknown Contact” record if the sender isn’t recognised.
In order to make it easier for you to implement your own custom workflow activity, you can download the source code here. In addition, if you wish to use the functionality as-is, I’ve also included the test workflow which you can import as a customisation, as well as the compiled assembly file – all you have to do is register it with your own CRM application.
This posting is provided “AS IS” with no warranties, and confers no rights.