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”;
 
    req.send(JSON.stringify(account));
 
    if (req.readyState == 4) {
 
        if (req.status == 204) {
          alert(“Completed with Success”);
        } else {
            var error = JSON.parse(req.response).error;
            alert(error.message);
        }
    }

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

clip_image001

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

image