In almost all the complex systems that I’ve worked with, there has always been a need to store some configuration information. It could be URLs to external APIs or web sites, connection strings to a database for integration purposes, application specific parameters that drive business logic such as Security Roles, Accounts or Contacts. In Dynamics CRM/365, there is often a need to store the same type of information so that plugins, workflow and other integrated applications read them and perform business operation accordingly. In this article, I share the most common options and share some pros and cons associated to each of them.
Key Value Pair Entity
IF you’ve done some application design, you know what the concept of a key value pair table is. In the Dynamics CRM/365 context, it is an entity that contains two required text fields: one for the key and the other for the value. The key represents the name of your configuration variable and the value is, well, the value for the key. For each configuration element that needs to be stored in your system, you create a new row with a key and its value. The images below provide an example of a Key Value Pair entity in CRM in which we stored information to connect to an external web service and the ID of a Security Role, all as text values.
1 – List of Key Value Pairs in Dynamics CRM/365
2 – Key Value Pair Entity for Example
- Very simple data structure
- Easy to add/remove configuration values
- Code to read and use the variables does not change over time
- Retrieving a config element is a fast operation (one row with two columns)
- Data type for the value is a text field (not practical for lookups or other data types as you may have to store GUIDs for example)
- Inability to set default values
- Inability to use FLS on specific config elements
- The Keys must be hard-coded in code and/or documented and maintained somewhere
If you are planning to use a Key Value pair type of configuration table, my recommendation is to have one key field as text, and configuration value type field (option set with the type of field – example text, two options) and multiple value columns of different types (e.g. Value (lookup 1), Value (lookup 2), Value (text), Value (two option)). As a bonus, you can add some business rules to prevent the selection of the wrong data type based on the selected configuration value type.
Here, the idea is to have an entity in CRM with one field for each configuration element that needs to be stored. In the example below, we have a table that contains information to connect to an ERP web service as well as credentials, and a lookup to a System Admin role (similar information as above). It in this case, there should only one row in the configuration table.
3 – System Configuration List View (only one row available)
4 – System Configuration Entity form (shows all the configuration fields)
- No need to have a list of configuration key names (use the field names enforced at the database level)
- Each configuration element has the appropriate type (e.g Lookup, text field, two option, option set etc.)
- Ability to enable Field Level Security on specific parameters
- Allows for default values for certain data types
- Easier to setup by an end user (create one row, set values as opposed to create multiple rows with key and value)
- Schema change + Code update required anytime a new configuration element is needed
- You need to ensure there is only one record for the entity (plugin validation on create)
- Configuration table grows horizontally and not vertically over time
I have used both models extensively and they both work well. For a stable system with not a lot of moving piece, I tend to like the Configuration entity better. For system where things change all the time and new config items need to be added on a regular basis, using the key value pair entity is often more cost-effective. There is also the possibility to use an XML web resource for parameters or the plugin secure and unsecure configuration fields.