Announcement: CRM Grid Editor now freely available

Until now the Limited Edition CRM Grid Editor has been available as a free add on. This edition has been limited to working with out of  the box entities and views. As of today, I am pleased to announce that this restriction has been removed. You can now obtain a free and unlimited version of the CRM Grid Editor which can (drum roll) also be configured to work against custom entities and views.

The CRM Grid Editor works with all versions of Dynamics CRM - on premise, online and IFD.

You can get an overview of product capabilities by viewing the CRM Grid Editor Summary video. You can also view the product installation video.


In order for you to be able to use the product it is necessary to generate a license file for your installation. To obtain a license please send me an email (see details in Contact tab) with the following information:

On Premise
Provide your CRM server URL and organization as shown in the screenshots below.

Online:
Specify the org name that you are using to access CRM i.e.: https://orgname.crm.dynamics.com



Key features:

• Simple and intuitive Excel-like interface 
• Edit all editable CRM fields returned in view (all data types handled) 
• Based on CRM view definitions – no additional setup required 
• Bulk update of records – make changes on the fly without having to save between row edits 
• Launch Grid Editor from context sensitive CRM user interface or as a fully navigable standalone application 
• Drill down to child records from a parent record – not limited to the associated view! 
• CRM Security model enforced – you cannot do anything with the Grid Editor that cannot be done through the standard CRM user interface 
• The Grid Editor can be configured to work against all CRM entities and views – including custom entities and personal views 
• Tabbed interface allowing multiple different views to be open at the same time 
• Ability to define and save "GE Views" which allows for advanced pivot table-like grouping and filtering 
• Add new records using the CRM standard, quick or the new Grid Editor view sensitive add-new form 
• Run CRM workflows against selected records

Other features include:

• Deactivate and Activate records in line 
• Manually execute CRM workflows 
• Link back to CRM records with a single click 
• Advanced additional filtering and sorting options 
• Easy to identify color for changed cells, columns 
• Dynamic export to Excel 
• Supports opportunity and case close forms 
• Supports Drag and drop editing and Undo Changes Requirements:

CRM 2011 Copy Utility

This plugin allows you copy fields from a parent record to all child records in a 1:N relationship. For example, this plugin can be used to copy the address fields of an account to all the contacts of that parent account (a common scenario).

Out of the box you are able to map fields from a parent entity to a child entity when the child record gets created. However beyond this point in time if details are changed on the parent record they will no longer be copied to the child records. Similarly there is no out of the box capability to copy changes made to the parent record down to all child records.

This plugin allows this option to be configured. You are able to configure which 1:N relationship this plugin will work against as well as the fields that are to be mapped between the parent and child entities. The plugin does not validate attribute types so you will need to ensure in your configuration that the fields be mapped are of the same type.

The following is a walk through of how to configure this plugin:

• Download the DLL from here
• Use the Plugin Registration tool to connect to your environment and register the plugin

• Register a New Step 
• Message: Update
• Primary Entity: Parent entity
• Remaining settings: Optional

• In the Unsecure Configuration update the XML to specify the fields to copy
• <setting name="source"> : parent entity name e.g. account
• <setting name="sourceid"> :  parent entity primary key e.g. accountid
• <setting name="target">  : child entity name e.g. contact
• <setting name="targetid"> : child entity foreign key e.g. parentcustomerid
• <setting name="numberoffield"> : total number of fields being copied
• <setting name="src_fieldn"> : name of source field to copy
• <setting name="dest_fieldn"> : name of corresponding target field to be copied too

Note: There is no validation of any of these fields. You need to ensure that:

• All the field names are correct
• The corresponding "src" and "dest" fields have the same definition 

For example, the following XML can be used to copy the address fields from the parent account record to the child contact records: 

<Settings>
<setting name="source">  
<value>account</value>
</setting>
<setting name="sourceid">  
<value>accountid</value>
</setting>
<setting name="target">
 <value>contact</value>
</setting>
<setting name="targetid">
 <value>parentcustomerid</value>
</setting>
<setting name="numberoffield">
 <value>8</value>
</setting>
<setting name="src_field1">
 <value>Address1_line1</value>
</setting>
<setting name="src_field2">
 <value>Address1_line2</value>
</setting>
<setting name="src_field3">
 <value>Address1_line3</value>
</setting>
<setting name="src_field4">
 <value>Address1_city</value>
</setting>
<setting name="src_field5">
 <value>Address1_stateorprovince</value>
</setting>
<setting name="src_field6">
 <value>Address1_postalcode</value>
</setting>
<setting name="src_field7">
 <value>Address1_country</value>
</setting>
<setting name="src_field8">
 <value>Address1_telephone1</value>
</setting>
<setting name="dest_field1">
 <value>Address1_line1</value>
</setting>
<setting name="dest_field2">
 <value>Address1_line2</value>
</setting>
<setting name="dest_field3">
 <value>Address1_line3</value>
</setting>
<setting name="dest_field4">
 <value>Address1_city</value>
</setting>
<setting name="dest_field5">
 <value>Address1_stateorprovince</value>
</setting>
<setting name="dest_field6">
 <value>Address1_postalcode</value>
</setting>
<setting name="dest_field7">
 <value>Address1_country</value>
</setting>
<setting name="dest_field8">
 <value>Address1_telephone1</value>
</setting>
</Settings>

• Register a New Image called "postEntityImage"

• Test and ensure that it is working

CRM 2011 UR12 and SharePoint Integration

After having applied the Polaris upgrade (update roll-up 12) the native CRM/SharePoint document integration stopped working. There were two different ways in which this issue manifested itself:

1. When clicking on the Documents link we just received the "spinning wheel" and the page did not load
2. On the occasion that it did succeed to load, the "New" and "Add" buttons did not work i.e. nothing happened at all when clicking those buttons preventing new documents from being added.

As I discovered, it is apparently necessary to update the List Components of SharePoint following the application of UR12. The updated List Components can be downloaded from the following location: 

http://www.microsoft.com/en-us/download/details.aspx?id=5283

This issue is also described in the following KB article along with the steps required for installing the List Component:

http://support.microsoft.com/kb/2810528

Xrm.Utility.openEntityForm no longer working

*** Update 3/5/2013: This issue has now been fixed via a Cloud update ***

Other known issues with UR12 can be tracked here: 
https://community.dynamics.com/crm/b/dynamicscrmsupportblog/archive/2013/01/28/december-2012-update-has-been-released.aspx

******

If you have a CRM Online installation and the Xrm.Utility.openEntityForm jscript function which you *knew* was previously working but apparently is no longer.... well, the good news is that you're not going mad. The bad news is that it is indeed a bug that has been introduced in the current (as of this writing) version of CRM Online. Or as confirmed from Microsoft:

Issue Definition: Xrm.Utility.openEntityForm does not work anymore since Update 5.0.9690.3339 on the CRM Online organization.

I have confirmed that this is an issue with the latest update that has been done with the CRM Online organizations. We are currently working on the code review and should have the fix in place shortly. 

The Microsoft support guy I spoke to indicated that this would likely be fixed within a week although I do not have a definitive date.

For the sake of reference below is the text of the error received when trying to use this form open utility.

Cannot sign in to CRM Online: LiveDevice.xml

Ok. I have stumbled on this too many times. Each time I think I'll remember for the next time and then, lo and behold, I spend time scratching my head trying to figure out what the issue is. So it's time I wrote it down - if nothing else for my own sake as a reference post (hopefully I'll remember that I wrote up this post!).

What am I talking about?

Trying to connect to CRM Online. It happens on occasion that I am denied access to CRM Online when trying to connect from a 3rd party application when I'm certain that my credentials are correct. For example, below is what happens when trying to connect using the Visual Ribbon Editor tool.

Usually I spend time thinking that maybe my URL is incorrect. Maybe I should have left off the http/https. Maybe I should use the Organization Unique Name (appearing under Developer Resources in CRM) instead of the "friendly name" in front of the crm.dynamics.com etc. etc.

The solution of course is simply to delete the LiveDevice.xml file from under the Root\Users\<user>\LiveDeviceID folder and then to try and sign in again... Voila!

Perhaps now I'll remember for next time? Let's hope so...

Duplicate Field Mapping/Defaulting

I encountered a scenario where whenever a child entity is created from within the context of a parent entity, the mapping automatically creates two references from the parent entity on the child entity.

The reason for this is due to the fact that the parent entity is related in a 1:N relationship to the child entity more than once:

And each of these relationships automatically creates a mapping that resembles the one below. That is both mapping contain a link from the parent entity to each of the foreign keys from the child entity and you are unable to delete these as they are required by the CRM platform.

Moreover any mapping added to one of the relationships is automatically added to the other relationship (and vice versa). I can't figure out if this is absolutely necessary from a technical design perspective or if this is just a design flaw. I suspect the latter because I can't come up with a good reason for this design logic. Or it could just be something specific that managed to sneak into the environment I'm working in.

The major issue is that this results in a confusing design because both fields get defaulted when only one should depending on the navigational context i.e.:

• When navigating from "Entities Owned" the "Entity" field should be defaulted from the parent entity whereas the "Is Invested In" entity should remain null
• Conversely, when navigating from "Investors in this Entity" the "Is Invested In" field should be defaulted from the parent entity whereas the "Entity" should remain null

As standard field mapping seems to rule out the ability to differentiate between these two different contexts, the only way to do so would seem to be by passing in custom parameters which is an example of when this technique is absolutely required.

To do so, the form was modified to remove the default "Add New" buttons and replace with custom Add buttons (which as an aside also provides the ability to give much clearer names to the add operation). The Ribbon Workbench Tool ably supports this kind of configuration. Each of these buttons simply calls the Xrm.Utility.openEntityForm to open the same child form button, but passes in parameters to set the lookup fields as required in each case.

Access Main form fields from Nav Area via Jscript

Let's say you need to access form fields via jscript when you have navigated to one of the navigational links on the entity. For example, when the account form is open but you are currently on the "More Addresses" navigation.

A typical scenario for such a requirement is if you have configured a custom button on the sub-grid ribbon that links to a jscript function where you need to pass through some parameters that are set from fields on the main form.

If you try and access the fields using the standard Xrm.Page approach while in the above navigational scenario, your jscript will error out. Like so:

function CustomAction() {

 var parameters = {};
 parameters["snt_customid"] = Xrm.Page.data.entity.getId();
    parameters["snt_customidname"] = Xrm.Page.data.entity.attributes.get("snt_name").getValue();
 
 Xrm.Utility.openEntityForm("snt_custom", null, parameters);

}

The solution is pretty much the same as how page elements are referenced from html web resources linked to a form i.e. using the prefix of "window.parent". Therefore updating the function as follows should do the trick:

function CustomAction() {

 var parameters = {};
 parameters["snt_customid"] = window.parent.Xrm.Page.data.entity.getId();
    parameters["snt_customidname"] = window.parent.Xrm.Page.data.entity.attributes.get("snt_name").getValue();
 
 Xrm.Utility.openEntityForm("snt_custom", null, parameters);

}

Update:

The above design has one flaw and that is if you decide to use a sub-grid to bring in the navigation link into the main body of the form. When you do so, the same sub-grid menu shows up when you click on the sub-grid but there is one essential difference...

In the case of the former, the main form is no longer in view and therefore you cannot access the form elements (Xrm.Page.data) without using the "window.parent" prefix. I you don't use this prefix you will receive a jscript errror.

In the case of the latter the main form is still in view and therefore Xrm.Page.data is accessible. And therefore if you use the "window.parent" prefix you will receive a jscript error.

In order to cater for both scenarios the solution is quite simple - simply use the try/catch exception handling feature. This way if an exception occurs it will go to the alternate access method which will then succeed.

function CustomAction() {

 var parameters = {};
 var id;
 var name;
 try {
  // if called from Nav Link navigation
  id = window.parent.Xrm.Page.data.entity.getId();
  name = window.parent.Xrm.Page.data.entity.attributes.get("snt_name").getValue();
 } catch (e) {
  // if called from Embedded Grid navigation
  id = Xrm.Page.data.entity.getId();
  name = Xrm.Page.data.entity.attributes.get("snt_name").getValue();
 }
 parameters["snt_customid"] = id;
 parameters["snt_customidname"] = name;

 Xrm.Utility.openEntityForm("snt_custom", null, parameters);
}