Additional uses of Custom entities and Configuration Data in your Dynamics 365 Solutions

In my last article I showed you how to manage configuration data as part of your Dynamics 365 solution deployments, as configuration entity data plays an important role for XRM solutions built for Dynamics 365, the best examples are Unified Services Desk and Portals but the same applies for most ISV solutions created for Dynamics 365.  We can leverage on custom entities to provide to provide additional value in building our XRM solutions as long as we ensure we ship any config data in the solution package.

Your Dynamics 365  Solution may contain additional configuration data making use of custom entities to hold important configurations that your bespoke solution logic is heavily dependent on. Your Workflows will need to reference these entity lookups whether it is a custom entity or team / queue etc otherwise your solution deployments will require a lot of manual interventions post deployment to fix the missing references that make your solution logic function.

Lookups

The most common type of configuration entity used are Entity lookups, by simply creating a N:1 relationship with a custom entity we can have a lookup instead of a hard coded optionset. This means options can be updated via configuration rather than requiring a solution update. Filtered lookups can also be achieved out of the box with no code and simple to configure.

Configuration Data 

Leveraging on custom entities to deliver the parameters we require to define logic allows us to deliver XRM solutions such as Unified Service desk and Portals serving as perfect examples. Dynamics 365 Portals acts very much like a CMS Website, as records created for Web Pages, Entity Forms, Entity Lists, content snippets provides the information to drive the behavior or the site. These solutions refer to the custom configuration records that are created by the users to generate web pages, and the same applies to the Unified Service Desk application behaviour dependant on the customer entities to drive the behaviour of Hosted Controls, Scriplets, Toolbars etc.

Plugin Configurations

I have often used Custom entities to hold important parameters to define plugin logic, the most famous example is my Free Autonumber Plugin or Dynamics 365 Entity Rollup solutions that allows the end user to define the parameters for operations by completing the values required for the configuration record. The On Create event is triggered on creation of the record which then triggers the plugin workflow activity to reference the new parameters.

Hardcoded Paramaters in Scripts

Instead of hardcoding your Url’s for Hyperlinks and Webresource References in Javascript, why not  prevents having to rebuild solution for each deployment

Your references used in your Javascripts and web resources for specific Urls is something you do not want to hardcode as they may differ from dev to uat and production. So one approach is to use a custom configuration entity to store these values so they can easily be changes from environment to environment by non developers.  This also means you no longer have to keep  rebuilding your solutions for each deployment down stream.

To help you feel free to use the following scipt to reference your config data rather than hardcoding your Urls;

function retrieveConfig(keyName)

{

var req = new XMLHttpRequest();

req.open(“GET”, Xrm.Page.context.getClientUrl() + “/api/data/v8.1/new_config?$select=new_value$filter=new_name eq ‘” + keyName + “‘&$count=true”, true);

req.setRequestHeader(“OData-MaxVersion”, “4.0”);

req.setRequestHeader(“OData-Version”, “4.0”);

req.setRequestHeader(“Accept”, “application/json”);

req.setRequestHeader(“Content-Type”, “application/json; charset=utf-8”);

req.setRequestHeader(“Prefer”, “odata.include-annotations=\”OData.Community.Display.V1.FormattedValue\””);

req.setRequestHeader(“Prefer”, “odata.maxpagesize=50”);

req.onreadystatechange = function () {

if (this.readyState === 4) {

req.onreadystatechange = null;

if (this.status === 200) {

var results = JSON.parse(this.response);

//var recordCount = results[“@odata.count”]; // To Get the Count

for (var i = 0; i < results.value.length; i++) {

var value = results.value[i][“new_value”];

}

}

else {

alert(this.statusText);

}

}

};

req.send();

}

Entity Privilege Rule

Another useful usecase for custom entities is the additional security role that is automatically created, this new entity privelidge rule can be used to provide further logic on your custom Ribbon buttons and Sitemap. I have written indepth about how to leverage on the EntityPrivelidge rule in the following articles;

http://www.crmconsultants.co.uk/hiding-command-bar-buttons-in-dynamics-crm-using-custom-security-role-privileges/

http://www.crmconsultants.co.uk/creating-a-role-based-sitemap-navigation-in-dynamics-crm/

Using custom entities and configuration data creatively mean means you no longer need to hardcode variables and allows you to create simpler solutions that are easier to manage and deploy. Please refer back to the following article to help you with managing your configuration data;