Friday, 2 August 2013

Code to Get the Sub grid row values in Mscrm 2011

    function GettheSubGridRowValues() {

       // Get the Grid conrttol using its name
      var  grid = document.getElementById("Events");
      // Chek the grid is loaded or not
       if (grid.readyState != "complete") {
        // delay one second and try again. to wait  for grid loading 
        setTimeout(SubGridRefresh, 1000);
    if (grid) {
         var gridControl = document.getElementById("Events").control;
        //Get the Row ids 
         var  ids = gridControl.get_allRecordIds();
         var  IslogicExecutionRequired= false;
        //Iterate by row wise
        for (i = 0; i < ids.length; i++) {
              // Get the call value by its column name
            var cellValue = gridControl.getCellValue('sci_name', ids[i]);
             if (cellValue == "xxxxx") {
                  IslogicExecutionRequired= true;

Attaching Sub Grid Refresh Event In MSCRM 2011

var grid = null;
var gridControl = null;
var ids = null;
var IsScottsdaleShowdown = false;

// call this finction on form laod
function Form_onload() {

// time out set as the grod will load littile late asynchronously after form laod , so we are waiting 2.5 seconds
    setTimeout("SubGridRefresh();", 2500);

// Attach  Sub grid refresh event
function SubGridRefresh() {

     grid = document.getElementById("Events");

     // Chek gris controll loaded or not 
    if (grid.readyState != "complete") {
        // delay one second and try after one second whether grid is loaded or not  
        setTimeout(SubGridRefresh, 1000);

    if (grid) {
    // Attach  grid refresh event
        grid.attachEvent("onrefresh", CustomLogic);



    function CustomLogic() {

// Write the custom Logic which need to be executed in Grid Refresh.

Thursday, 18 July 2013

Gathering requirements @ MSCRM

Enterprise Microsoft Dynamics CRM implementations  Gathering requirements

Gathering requirements and setting the right expectations is one of the areas which can make or break a Customer Relationship Management (CRM) implementation. When working with COTS packages, asking a customer “What do you want?” without first showing what there is, is a ‘lose-lose’ scenario. This approach will likely result in unnecessary requirements which are not aligned with the package you are implementing.

One thing to start off with is to have a structured platform in place where you can store requirements. In smaller projects this can be as simple as an Excel spreadsheet, whereas in enterprise scenarios you would benefit from using an enterprise tool like Caliber or Microsoft Team Foundation Server. In any case, it is critical that the functional requirements can be viewed by multiple people at the same time and that they are under source control. This way you can go back and see when and why this requirement changed and avoid numerous discussions later on.

Seven-step process
Once your platform to store the functional requirements is in place, the actual requirement gathering can start. From my experiences I have created a seven-step process which will help guide you through this phase.

1. Identify one or more client stakeholders (I strongly advise having less than 3 people) who have strong expertise around the business processes. These are people who can make decisions and are willing to defend them on behalf of their line of business.

2. Introduce these people to the look and feel of your CRM product of choice using a general product demo. Show them how to navigate, how to perform Create, Read, Update and Delete (CRUD) operations, etc. .

3. Use a questionnaire to have a high-level conversation around requirements. In most enterprise projects, you will already have gone through a number of discovery workshops in the pre-sales phase where a lot of valuable information should be captured already. 

4. Discuss these requirements with your CRM tool subject matter experts (SMEs) and let them come up with feedback and a high-level solution design for each of these requirements. For example, if a customer is looking for functionality X, but the COTS tool works in a different (Y) way,  your SME should advise that functionality Y provides similar functionality and will keep the risk and costs lower.

5. Based on the SME’s recommendations and high-level solution design, have your development team create a number of proofs of concepts (PoCs). Make sure that at this point the developer standards and best-practices within the development team are already finalized, Otherwise you’ll end up refactoring a lot when the actual development phase starts. From my experiences, 80% of your proof of concept should be re-useable when starting the actual development phase.

 6. Demo these PoCs to the customer and then have the conversations around the detailed business processes. When the business stakeholders can actually see what the tool can do, it will be a lot easier for them to come up with requirements that align with the “out of the box” solution.

7. Input all of these requirements into your platform of choice.  The next step is then to start prioritizing the requirements on importance and business value. The final goal should be to have a clear phased approach in place with big chunks of functionality to define the scope of the several phases.

The final action is then to get a sign-off from your customer on this scope and then all of this information can be given back to the SMEs and development team so they can create a technical design document for your first phase scope. It is wise to hold off on the detailed phase 2 scope until you get to a state where the phase 1 development is almost finished, as this is something which can change based on questions and feedback on the development of phase 1.

 When you get closer to the deadline of your phase 1 go-live, pressure will rise and certain gaps will be identified which might result in last-minute change requests for your phase 1. My advice here is that this can become a never-ending cycle and the only way to get out of this is to freeze your phase 1 scope and place further change requests in a future phase.

A final point to stress is that it is also very important to keep updating your functional and technical design documents during the implementation. Otherwise you’ll end up in a situation where your documentation is out of sync with what is actually developed and the testers will start raising false defects, and confusion will arise on what was agreed.

 Gathering requirements is a very important milestone in every CRM implementation which should not be underestimated. The key objectives should be to set realistic expectations, define a clear scope, and keep aiming for win-win scenarios where you use as much out-of-the-box functionality as possible. As an enterprise service provider, Hewlett-Packard has a global pool of expert resources that can help guide you through this process. If you would like to find out more about this, please get in touch by sending an email to

Thanks for reading!

Dependent Picklist in MScrm 2011

Dependent Picklist in CRM 2011

             MS CRM 2011 doesn't have Out-Of-the-Box functionality to filter the option set values based on the value selected in another option set. We can implement this functionality using Javascript. Lets consider one example here. We have two option set fields called Country and City. City field has to be filtered based on the value selected in Country field. Below JScript code will do this functionality.


1. Create two optionset fields named new_country(with values say, India, USA and Srilanka) and new_city(with values say, Bangalore, Delhi, New York, Colombo, California and Hyderabad).
2. Create a JScript Webresource with the below code.
3. Attach this webrecource to call optionSetChanged() method on change of Country field and OnLoad of the form.
4. Configure getCollection() method to match the Cities with respect to Country.

Functionality: To populate the picklist values based on the value selected in another picklist.
Field Name: new_country
Field Event: OnChange, OnLoad

function optionSetChanged() {

    /// Change the dependent picklist values based on the value selected in the control picklist.

    var _collection = getCollection();
    var _selectedCity = null;
    var _cityOptionset = Xrm.Page.ui.controls.get("new_city");
    if (_cityOptionset != null)
        _selectedCity = _cityOptionset.getAttribute().getValue();

    var _cityOptions = _cityOptionset.getAttribute().getOptions();
    var _selectedCountry = Xrm.Page.getAttribute("new_country").getText();
    // If Country is empty, then clear the City field.
    if (_selectedCountry == "") {
    else {
        for (var i = 0; i < _collection.length; i++) {
            if (_selectedCountry.toLowerCase() == _collection[i].Country.toLowerCase()) {
                for (var j = 0; j < _collection[i].Cities.length; j++) {
                    for (var k = 0; k < _cityOptions.length; k++) {
                        if (_collection[i].Cities[j].toLowerCase() == _cityOptions[k].text.toLowerCase()) {
        if (_cityOptionset != null && _selectedCity != null)

function getCollection() {

    /// Creates and returns a collection of Cities with respect to their Countries.

    var _collection = new Array();
    var India_Cities = new Array("Bangalore", "Delhi", "Hyderabad");
    var India_obj = { Country: "India", Cities: India_Cities };

    var Srilanka_Cities = new Array("Colombo");
    var SriLanka_obj = { Country: "SriLanka", Cities: Srilanka_Cities };

    var USA_Cities = new Array("California", "New York");
    var USA_obj = { Country: "USA", Cities: USA_Cities };

    return _collection;

    This functionality can be tested by changing the Country field and check the values populated in City field. Result of this dependent pick list is can be seen here.

Country: India and Cities: Bangalore,Delhi & Hyderabad.

Country: USA and Cities: California & NewYork.