Web API–Status update and SetState message Plugin


With Web API, now we can call the Update method to change the Statecode and Statuscode on the entity. This was not possible earlier with REST OrganizationData.svc endpoints.

On one hand it does makes it simpler to change the Status of the entity along with other attributes, one thing developer should keep in mind that. Now with Status Change, CRM will invoke Update message of and not SetState or SetStateDynamicEntity. It would be safer to register all 3 messages, that is Update, SetState and SetStateDynamicEntity so that all possible scenarios are covered.

Following is sample WebAPI code which update Account Status, this code will invoke Update message in Plugin.

    var entityId = Xrm.Page.data.entity.getId();
    var clientURL = Xrm.Page.context.getClientUrl();
    var AccountName = Xrm.Page.getAttribute(“name”).getValue();
    entityId = entityId.replace(“{“,””);
    entityId = entityId.replace(“}”, “”);
    var req = new XMLHttpRequest();
    var odataQuery = encodeURI(clientURL + “/api/data/v8.0/accounts(” + entityId + “)”);
    req.open(“PATCH”, odataQuery, false);
    req.setRequestHeader(“Accept”, “application/json”);
    req.setRequestHeader(“Content-Type”, “application/json; charset=utf-8”);
    req.setRequestHeader(“OData-MaxVersion”, “4.0”);
    req.setRequestHeader(“OData-Version”, “4.0”);
    var account = {};
     // State code value
    account[“statecode”] = 1;
    //  status reason Value
    account[“statuscode”] = 2;
    // Normal field Update   
    account[“name”] =  AccountName + ” Status Changed”;
    if (req.readyState == 4) {
        if (req.status == 204) {
          alert(“Completed with Success”);
        } else {
            var error = JSON.parse(req.response).error;

Entitlements…some of the limitations we faced


CRM has entitlements since CRM 2013 and it was major functionality addition for Service Management. For our Service Module implementation we decided to implement Entitlement, however sooner we found that our functional requirement does not fit into OOB Entitlement functionality and finally we have to opted for Custom Solution.

Let me explain what we intended to do

  1. In CRM we had Customer Hierarchy enabled in a such way that there would be Parent Customer at root and it will  have children Customers from various regions. Logically its one customer only however we have to maintained the hierarchy because products can be sold to any of the Customer in Hierarchy.
  2. Since we treat all the Customer is entire Hierarchy as “One” logical customer, there are no separate entitlements for each of these Customers, all the Customers in a hierarchy follow the same entitlements and SLAs
  3. On Cases for Contacts there are 2 fields provided, one is responsiblecontactid and other one is primarycontactid. As you might be already knowing, primarycontactid is tightly coupled with customerid field in sense that when Customer is selected as Account only Account-Contacts can be assigned to primarycontactid field on Case. On the other hand responsiblecontactid  is stand alone field having no dependency on any other field. We for our Case form selected primarycontactid to capture the Contact on Customer.


Now here is what we faced as limitations.

  1. We had defined Entitlements only for Root level  (Parent) Customer in CRM, hence there was just one Entitlement per Customer Hierarchy.
  2. There were no Contacts added to Entitlements.
  3. There were no Products added to Entitlements.
  4. Cases can be created for any Customer within Hierarchy and Contact was mandatory field on Case form. Hence every case would have Customer (Account) and Contact.
  5. Now in such cases System would not match Entitlement since it would never match the Customer and Contacts on Case with Entitlements.
  6. Even though User tries to select the Entitlement on form it will throw error as shown below


One of the solution to overcome these limitations was to create “same” entitlements for each of the Customers in Hierarchy which we this would be maintenance overhead if we have to alter Entitlements for Customer.

So basically we could not leverage OOB Entitlements for our Business Process.

I think there should be some enhancement made to Entitlements functionality to honor Hierarchy of Customer so that we minimize creating Entitlements for all the Customer in hierarchy.

Using Alternate Keys for Duplicate Detection


Earlier to “Alternate Keys”, for Duplicate Record detections developer either rely on Duplicate Detection rules or write Custom Plugin. Each of it has its own advantages and disadvantages.

Duplicate Detection rules are codeless and quick to set up however they do not block users by creating Duplicate records, users can accept the warning and proceed to create duplicate records.

Custom Plugins, need custom coding and and it will completely block users from creating duplicate records, however its not flexible as Duplicate Detection rules.

With invent of “Alternate Keys”, we can use it in place of Custom Plugins and we still do not have to create custom plugins. Once Alternate Keys are define CRM platform restrict users from creating duplicate records

Only disadvantage of it is you can have Custom Error Messages which will describe the error in User friendly way

Following is the message that is thrown by CRM


CRM Generic Hierarchy Child Entity Sub-Grid

From Microsoft Dynamics CRM 2015 Hierarchical Visualizations allows the end user to visualize and interact with hierarchical data in an intuitive and visual fashion across both the web and the tablet.

This is great feature where User can visualize Hierarchy. However it would have been better to apply same hierarchy functionality for Child entities of Entity on which Hierarchy is set up. For example Account has Hierarchy settings where Parent Account is lookup on Account entity. Account has one to many relationship with Cases, Opportunities, Contact etc. So User would like to see the all the Cases which are created “Under” the particular Account. Here phrase “Under” means all the Cases for particular Account and all the Cases for the Account Under this Account.

Currently CRM does have this feature available but in very limited way that too only for Account entity (Correct me if I am wrong here).

My managed solution address this problem and with few Click and Point settings (no coding involved) CRM Customizer can set up the Sub-Grid view on Parent Entity form to show all the Children that comes “Under” the parent Entity record

More details where you can download managed solution at https://generichierarchychildentitysubgrid.codeplex.com/


CRM 2015–Incoming emails are not getting created as Email Activity


If you have 2 or more Queues with same Incoming email address and if one the the Queue is Inactive then one would expect CRM Server Side Synchronization to process the email and assign it to all the Active Queues for that email address.

However actually CRM Server Side Synchronization will not process such emails and not Email activity will be created.

On CRM Mailbox, ALERTS something like following will be captured.




If you look into Trace logs you will find error logged as

>Crm Exception: Message: You cannot add items to an inactive queue. Select another queue and try again., ErrorCode: -2147220190, InnerException: Microsoft.Crm.CrmException: You cannot add items to an inactive queue. Select another queue and try again.

Resolution for this problem is if you do not want to use the Inactive Queue, clear its Incoming Email value and deactivate it again.