Resource not found for the segment ‘AccountSet’

Issue:

If you are getting error when REST call is made to https://<<Org Name>>/xrmservices/2011/OrganizationData.svc/AccountSet(guid’FA18CED8-FBBB-E711-9110-005056B860DB’) saying Resource not found for the segment ‘AccountSet’. And if you trace this call in fiddler you might get response as HTTP/1.1 404 Not Found.

Resolution:

Reason for this error is User who is invoking this call does not have permissions to read the AccountId.


Advertisements

Dynamics CRM 365 – clearOptions()

For Dynamics CRM 365,

Xrm.Page.getControl(arg).clearOptions() method will implicitly call OnChange event of the CRM OptionSet Attribute. This causes one UI behavior which some times might confuse Users, if OptionSet field is defined Mandatory.

Take a example of the Form which has OptionSet field placed on it. And you have JavaScript triggers on Page Load which basically wanted to control the items in the OptionSet attribute based on Security Role of the user or any similar logic.

Now most common practice is we remove all items by calling clearOptions() method on CRM Control and then add the desire items to same Control using addOption() method.

Prior to Dynamics CRM 365, this would work without any problem. However in Dynamics CRM 365, once the form is loaded without User doing anything it will show up , Red Circle (Validation Failure) for Option Set field.

image

This Validation error might confused some User as why are they shown error when they have not yet started entering data.

To avoid this there small trick that works well in this scenario, just remove the Mandatory required level before calling clearOptions() and apply it back after.

E.g.

Xrm.Page.getAttribute(‘new_quotingcustomer’).setRequiredLevel(‘none’)
Xrm.Page.getControl(‘new_quotingcustomer’).clearOptions();
Xrm.Page.getAttribute(‘new_quotingcustomer’).setRequiredLevel(‘required’)

Dynamics 365–Behavior when Lookup field is set in JavaScript

When you set value for Lookup attribute using JavaScript, with Dynamics 365 we have to take care of following issues which were not there in previous versions.

Problem: Problem is if any of the Lookup attribute  values are changed before Save then once the Save is completed it will trigger OnChange event of the Lookup attribute.

  • When setting id property make sure that GUID is enclosed in curly braces and its all UPPER Cases
    • Following code will cause OnChange event getting triggered
      var lookupItem = new Object();
      lookupItem.id = ‘{6976e322-1d82-e711-80ec-005056b80363}”;
    • Following code should work without any problem
      var lookupItem = new Object();
      lookupItem.id ='{6976E322-1D82-E711-80EC-005056B80363}’;
  • When setting entity logical name you could have used typename earlier without any problem however this property is no more supported and should be replaced by entityType
    • Following code must be avoided
      var lookupItem = new Object();
      lookupItem.typename = ‘new_protochildentity’;
    • Following is correct way to set entity logical name
      var lookupItem = new Object();
      lookupItem.entityType = ‘new_protochildentity’;
  • Also name property should also match exactly

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

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/