Working with key-value pair data inside Microsoft Dynamics CRM workflows

by Lucas Alexander

Dynamics CRM workflows are a great way to enable business processes, and with the real-time capabilities introduced in CRM 2013 they can replace plug-ins in many scenarios. One significant drawback that workflows do have, though, is they lack the ability to easily retrieve and work with data from inside Dynamics CRM that is not related to their primary entities.

For example, let's say I have a workflow that creates a task if a contact's credit limit is greater than $5,000. In a completely custom software application, I would store this threshold value in some sort of configuration data store from which it could be retrieved at runtime, but Dynamics CRM doesn’t support that pattern out of the box. This requires that the $5,000 value be hardcoded in the workflow. If the credit limit threshold is reduced next month to $4,000, the workflow will need to be deactivated, then the value will need to be changed, and the workflow will need to be reactivated. Potentially more troubling, if this credit limit threshold value is used in multiple steps (or even multiple workflows), it's possible for it not to be updated correctly in all of them.

In this two-part series I will show how to create a solution for managing and consuming configuration data that uses a key-value pair data store in Dynamics CRM. In addition to solving workflow-specific issues, this basic approach could easily be leveraged in plug-ins, actions and other custom CRM-interfacing code.

Getting started

First, what exactly is a key-value pair? From the Wikipedia "attribute-value pair" entry:

A name–value pair, key–value pair, field–value pair or attribute–value pair is a fundamental data representation in computing systems and applications. Designers often desire an open-ended data structure that allows for future extension without modifying existing code or data. In such situations, all or part of the data model may be expressed as a collection of tuples <attribute name, value>; each element is an attribute–value pair.

Storing the data

To store key-value pair data in Dynamics CRM, all we need is a custom entity that stores the key in its name field and the value data in a value field. Because CRM doesn't have an "object" data type, we need to create a different value field for every possible data type we want to store. In this example, I have a custom entity called Key-Value Pair (new_keyvaluepair) that has the following custom fields to hold value data:

  1. String value (new_stringvalue)
  2. Decimal value (new_decimalvalue)
  3. Integer value (new_integervalue)
  4. Date value (new_datevalue)

Additionally, I have an optionset field called "Value type" (new_valuetype) that indicates what type of value the key represents. When the value type is selected, CRM business rules set the corresponding value field on the form to business required and the other fields to not required.

If I had selected a decimal type instead of a string, the decimal value field would be required instead of the string value field.

That's all for now. In my next post I will show how retrieve and consume the data inside a workflow using a custom workflow activity. See you then!

A version of this post was originally published on the HP Enterprise Services Application Services blog.