Update Rollup 5 for MS CRM 4.0 Released

Looks like the next rollup update is now available from Microsoft: http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=5101d801-976b-4c11-bdfc-000b970ef4a3

Including External JavaScript Files

There are a number of blogs out there with good information on how to include external javascript files in your CRM OnLoad events. I’m only adding this post to the mix to bring together some of the different information out there for easy reference.

CRM provides three primary places to add client-side code: OnLoad and the OnSave for the form, and OnChange for individual fields. In the form editor for an entity, OnLoad and OnSave scripts can be added to the form properties. Each field has its own properties area where OnChange scripts can be added.

For easier management of client-side code, we often use just the OnLoad area to store all the javascript we add for a particular form. We’ll define the functions we want to use throughout the form, and call them from field or form events. You can use attachEvent to hook into events on individual fields so you don’t need to add javascript behind every single field. An attachEvent works like this (notice my function is calling the FireOnChange method as well):

/* define your function */
function MyFunction(){
crmForm.all.myfieldname.FireOnChange();}

/* attach your function to the onclick event
crmForm.all.myfieldname.attachEvent('onclick', MyFunction, false);

Check out Mitch Milam’s blog at http://blogs.infinite-x.net/2009/04/20/changing-a-checkbox-field/ for a look at how he used attachEvent.

Taking this approach a step further, it sometimes makes sense to store the javascript in an external .js file. In that case, the form’s OnLoad properties will just contain a reference to an external file, sort of like an ‘include’ statement that appends our external .js file as the form loads in the browser. Here’s an example from http://www.henrycordes.nl/post/2008/05/External-js-file-and-CRM.aspx:

/* Place in the OnLoad area of a form */
function IncludeExternalScript(scriptFile)
{
  var netRequest = new ActiveXObject("Msxml2.XMLHTTP"); 
  netRequest.open("GET", scriptFile, false); 
  netRequest.send(null); 
  eval(netRequest.responseText); 
}
/* There is an ISV folder in the CRM webroot */
/* that your filepath should point to */
IncludeExternalScript('/ISV/_customscript/customscript.js');
CallFunctionInCustomScriptjs();

One thing to be aware of with this approach is that if you set up any users with the full Outlook client that allows them to work with CRM offline, all your calls to external script files will fail when they are offline since the file is on the CRM server. You can include a check before you add the external script and then do something like disable all the form’s fields if they are offline, but this starts to defeat the purpose of using the external file to start with.

Also, there are various methods of attaching external scripts. This method seems to work well, but you should be aware that the file will be cached in the browser, so if they make a change, users may not get the changes right away. One way around this is to go into IIS and navigate to the ISV folder and add a custom header to the external file to control caching. More info on this is at http://ronaldlemmen.blogspot.com/2008/07/javascript-files-and-caching.html.

The CRM Address Entity: There’s more to it than you think!

I’ve been working with Microsoft CRM in production environments since 1.2 was released, but apart from some minor tweaks to the form I haven’t had to work with the Address entity in too much depth. Until now. I was surprised to find that there are a lot of, er, “undocumented features” that make this built-in entity behave quite differently than I expected. The SDK has a few remarks about the Address entity, but it took me a while to put all the pieces together, and I thought I’d share what I’ve found:

1. Two blank address records are created for each Account and Contact. Out of the box, CRM Accounts and Contacts have built-in fields to capture two addresses. These fields are address1_street1, address1_city, address1_stateorprovince, etc., as well as another whole set for address2 fields.

Whenever an Account or Contact is created, the CRM platform creates two blank address records related to that parent Account or Contact.

The purpose of these two blank address records is to store synchronized data that is entered in the address fields on the Account or Contact itself. The platform handles keeping these two entities in synch. If you change the values stored in the Contact’s address fields, the associated Address record is updated automatically.

2. The first two Address records that the platform creates are hidden in the “More Addresses” associated view on the Account or Contact. I guess this is because these addresses should be maintained on the Account or Contact, not in the Address entity itself. The purpose seems to be so that addresses added on the Account or Contact form are available when you do an address lookup on a quote or order. (Note that you’ll need to enter data in the “Address Name” field on the Account or Contact if you want it to show up in the Address Lookup view as well.)

3. You cannot update the Address record via workflow. You can create workflows based on the Address entity, but it’s not available to update itself. Not sure why, though…

4. You can’t modify the relationship mappings between the Account entity or the Contact entity and the Address entity. And you can’t add custom relationships to the Address entity.

5. Addresses are not available on Security Roles. You want to restrict users from editing or deleting Addresses? Can’t do it, at least not with Security Roles. Go figure…

6. There’s no built-in way to add the parent Account or Contact to the Address form. Adding the “Parent” field to the Address’s Advanced Find or Lookup views only returns a blank column as well. This seems to be a shortcoming or a bug of some sort. For all other entities with a N:1 relationship, you can add the ‘1’ part of that equation to the ‘N’ form. For example, if you create an entity called “Projects” with a N:1 relationship to Accounts, you can add the Account lookup field to the Project form. The lookup field actually consists of an array that contains a GUID, a string for the record’s name, and the object type code (OTC). In the case of Addresses, the only thing stored in the Address table is a field for the GUID. Without the name of the related object and the OTC, the interface can’t present a normal, functioning lookup field.

WORKAROUNDS:

With all of these limitations, organizations that need to manage multiple addresses for their Accounts or Contacts, and that need to perform logic against these addresses regularly, may need to do some workarounds. Among the options to consider: create a plug-in that “un-hides” the first two address records so they’re visible in the “More Addresses” associated views. Another option would be to create a custom entity with a N:1 relationship to the Account or Contact. This option has the benefit of allowing you to do the full range of mappings and workflow that you can do with just about any other entity. The downside is that if you want the address fields on the Account or Contact to be used and available for mail merges and Outlook synchs, the custom entity option will require some more create workflow solutions.

New Updates and Rollups

I haven’t had a chance to blog in a couple of weeks, and there have been a number of new releases from the CRM team at Microsoft:

1. Update Rollup 4 has been released.

2. The Implementation Guide has been updated.

3. The SDK has been updated, and

4. The CRM On-Premise Help files have been updated. (Remember to backup your Help files if you’ve customized them!)

New Article on the Microsoft CRM Team Blog

I have a new article on the Microsoft CRM Team Blog today with some tips on building a virtual development server for CRM using Windows Server 2008 and SQL 2008. Check it out!