CRM 2011 OnClick Events

My former post highlighted the fact that the 4.0 syntax (unsupported though it was) no longer works in CRM 2011 and in fact has a lot more nefarious side effects than just not working as it should...

So how can the OnClick event be replicated in CRM 2011? The inspiration for my answer was provided from this post. I took the example that was provided and stripped it down to the following function:


function RegisterOnClickEvent(attr, fn) {
var e = document.getElementById(attr);  
    var f = "var click=function() { " +  
              fn + "(); " +  
" };";  
  
    eval(f);  

    // Attach to click event  
    e.attachEvent("onclick", click, false);  
}


Thereafter all you need to do to register an OnClick event for a bit field is to pass the following function call:

RegisterOnClickEvent("attribname","functionname");

CRM 2011: Error on page

While upgrading a CRM 4.0 environment to CRM 2011, I had to contend with the "Error on page" issue. That is, there was something in the jscript of the page that CRM was not liking which caused the page to render as with the "Error on page" message when loading and consequently with the "Microsoft Dynamics CRM has encountered an error" message when exiting the form.

I was further perplexed by the fact that this error did not appear to have anything to do with the form jscript as I disabled all onload and onchange events and yet the error did not go away. However after additional testing it did indeed appear to be linked to the jscript as when I cleared out the jscript of the form (as opposed to just disabling it) the error went away. Why the jscript should be affecting the form in such a way even when it is disabled is beyond me. It seems to defeat the purpose of being able to disable the jscript. But this is the first lesson from this exercise - jscript can affect form rendering even when it has been disabled. Maybe Microsoft will fix this in a future release.

Ok. So having determined that jscript was indeed the culprit the hunt was on to determine exactly which piece of jscript was throwing the form rendering off. This was a process of elimination whereby snippets of jscript would be removed until the offending jscript could be determined.

And what did it come to...?

I am sure this is not the only scenario which can result in this error but in my case it was because we had configured an on-click event for a field in the form. The 4.0 syntax of crmForm.all.field1.onclick = function() {} was troubling the application.

Once this had been removed the error went away... as did the cloud that was hanging over my head.

CRM 2011 Mashups

Earlier I provided an introduction to mashups in CRM 4.0 including downloads and instructions on how to configure this in your CRM 4.0 environment. This topic then segwayed into a discussion about integration approaches one of them of course being the mashup/virtual integration approach.

It's time now to come full circle and discuss how the mashup/virtual integration can be configured in a CRM 2011 environment. With the new configuration options provided by CRM 2011 it is no longer necessary to refer to an external redirection web page in order to accomplish the objective (using the Navigation Pane). We will step through this example by creating a mashup between a CRM account and a bing map (arguably the most "classic" of mashups).

• Navigate to Settings | Customizations | Custome the System | Entities | Account | Forms and open up the Main form

• Click on the Navigation icon. After clicking this the left navigation panel is enabled. 

• Navigate to Insert | Navigation Link and in the resulting dialog provide a Name and an Icon (none of the other fields need to be filled in - they will be provided at run time using jscript manipulation)

• Save and Publish the form
• Open an existing account, hit Ctrl+N to open it so it does not appear in application mode and launch the IE Developer Tools
• Search for the "Map" navigational item and when you locate it, copy the "navLink" item from the "id" attribute

• Copy the script below and replace the navlink id with what you copied in the above step

function Map() {


var addresr1        =Xrm.Page.data.entity.attributes.get("address1_line1").getValue();
var addresr2        =Xrm.Page.data.entity.attributes.get("address1_line2").getValue();
var city            =Xrm.Page.data.entity.attributes.get("address1_city").getValue();
var state           =Xrm.Page.data.entity.attributes.get("address1_stateorprovince").getValue();
var postalcode      =Xrm.Page.data.entity.attributes.get("address1_postalcode").getValue();


if(addresr1==null)
{
addresr1="";
}
if(addresr2==null)
{
addresr2="";
}
if(city==null)
{
city="";
}
if(state==null)
{
state="";
}
if(postalcode==null)
{
postalcode="";
}
var parmval=addresr1+" "+addresr2+" "+city+" "+state+" "+postalcode;


var navAcctVal = document.getElementById("navLink{4527a3a5-4173-43b8-3a08-da7da29a1ac2}"); 
if (navAcctVal != null && navAcctVal != undefined) 
{ 
var u1 = encodeURI("http://www.bing.com/maps/?v=2&where1="+parmval); 
navAcctVal.onclick =function () { loadIsvArea(Mscrm.CrmUri.create(u1), true); }; 
}


}

• Link the "Map" javascript function to the main form load event and publish
• The next time you load an account and click on the Map link, you should be able to see a context sensitive bing map linked to the account you are reviewing

Integration Approaches - part 3

In my previous post I discussed the second integration approach - that being virtual integration. This post will cover the third integration approach available.

In truth, this third integration approach is in essence a variation of the second integration approach which is why I mentioned at the outset that there are in fact only 2 high level approaches to integration.

This third approach leverages reporting capabilities in order to combine CRM with data from other systems. In many cases - especially when dealing with back office ERP or accounting systems - the application front end is a windows form application. That is, there are no URL-addressable pages that can be linked to in order to leverage the second virtual integration approach.

In such a case - if physical data integration is not on the cards for the same reasons as have been mentioned in my former post - then this reporting integration approach is likely the way to go.

The idea behind this approach is that if a standard report can be written to retrieve the data from the remote application database and be formatted and laid out as necessary, it can then be linked to CRM using the virtual reporting integration approach. This of course only holds true provided that the reporting tool you are using renders the report in html format. The best option for this approach is to use Sql Server Reporting Services (SSRS) while adhering to the CRM SDK standard for writing reports to target the Microsoft CRM platform (and using remote joins to connect to the remote database). By doing so, your report can be embedded into a CRM form and with a little bit of formatting the data can even be made to appear as if it resides natively in CRM.

You can refer to the following article for a step by step guide on how to leverage this report level integration option.

Integration Approaches - part 2

In my previous post I mentioned that there were essentially 3 integration approaches and discussed the first one - physical data integration - in depth. I will continue with the second type of integration approach in this post.

The second approach to integration is virtual. I have already addressed what this approach is all about while discussing the concepts of CRM mash-ups and therefore I'll not delve too much further with regards to this approach. This type of integration is a relatively new integration approach that is made possible through web technologies and URL-addressable forms.

This approach should therefore be used when linking to another application that can be accessed via a URL and linked in a context sensitive manner to the account, contact, etc. entity being viewed. It is the obvious (and perhaps only) choice of integration when integrating to a web page somewhere on the internet as illustrated by the Google map sample. However it is also a valid option as an alternative to the physical data integration approach especially when the volume and size of data being integrated to is large. As a rule of thumb, if none of the requirements for physical data integration exist (as listed in my former post) and the option for this virtual type is available (i.e. the application/web page is URL-addressable), then this type of virtual integration should be strongly considered as a method of application integration.

I'll address the third type of integration approach in my next post.

Integration Approaches

My former post explained how to go about using the "mash up" technique for integrating CRM with other applications. In so doing, it also touched on other approaches to integration. I thought I'd delve into that topic a little more in this post.

In essence I mentioned that there are 3 high level approaches when it comes to combining two applications together. Although technically - when it comes to it - there are in fact only 2 high level approaches to integration. But we'll come to that. This topic is not limited to Microsoft CRM but can apply when integrating any two systems together.

The first approach is physical integration. That is, data in one system is physically moved to another system. This is perhaps the most common form of integration and is most often what people think of when they refer to the term "data integration". Of course there are many different methods of going about physical data integration be it real time integration, close to real time integration, batch integration, and file imports/uploads. And there are various mediums/formats that can be used for integration such as web services, XML, CSV, stored procedure, direct database querying/updating and so on. But at a high level these all represent a single approach to integration - that being the physical transfer of data from one system to another. Perhaps at another time we can perhaps delve into these different methods, mediums and formats for integration highlighting pros/cons to each of them and when they may or may not be appropriate.

Physical integration is required in any one of  the following use cases:

• Data Continuity - The data starts in one system and needs to be "embellished" on via the CRM user interface and perhaps passed back to the original application to form a 2-way integration or onto another application.
• Data Accessibility - Sometimes data needs to be updated in 2 systems because that's just the requirement. For example, accounting personnel will need to update an account record in the back office accounting system and the sales team will be updating the same information (perhaps with checks/balances) via the CRM front end.
• Reporting - Data needs to be reported on from within the CRM database
• Workflow - Data brought into CRM is used to trigger workflows. For example, an escalation or approval workflow being triggered off an account billing status.
• Offline requirements - If the data is required offline then it will need to flow into CRM in which case, CRM's syncing capability with Outlook can be used to bring the data offline 
• Mobile requirements - Similar to the offline requirement. If the data needs to be synced with a mobile application it will need to be passed into CRM.
• Security - Not a very common scenario, but if the data coming in has security restrictions in terms of who can view it, then CRM's security model can be applied against it if the data physically resides in CRM.
• No other way - It could be that the source system is not accessible by any other means than via data integration. This could be if the application has some flat file format, is stored in a spreadsheet, or some other variation that makes connecting to the information through any other means other than data extraction/integration impossible.
  

Physical integration may not be a good idea in the following scenarios:

• Size of data - If the data on the other side is very large (in the millions, tens of millions and beyond) or changes very rapidly it might be unwise to do physical data integration due to the volume of information that will constantly be flowing back and forth. This could be true of invoices or supply chain information.
• Simplicity - Physical data integration may just not be necessary or it might be simpler to use a different approach either for the short term effort or long term maintenance effort or both. Remember that integration is something that over time needs to be maintained and if having a more "static" approach will work then this may be the better option.
• Tools - If you don't have the right tools for integration and have budget restrictions in that regards then you should probably look into other alternatives.

As alluded to by the last point above, when physical integration is required then you are best off ensuring that you have the right tools for the job. I have already discussed this topic in depth  a former post in case you want to get a perspective on this.

I will discuss the other integration approaches in separate postings.

CRM 4.0 Mashups

In CRM 4.0 we have the ability to create "mash ups" in order to combine CRM with other web applications. This essentially creates a visual integration between CRM and the other application such that an end user does not necessarily know where one application begins and the other one ends. This "graying" of the application boundaries is a good thing as at the end of the day, an end user should be prevented from having to access silos of information in favor of having a single access point for all relevant business data. Be it, native CRM data, physically integrated accounting data, or visually joining the applications as in this case.

This kind of integration could be achieved by either employing the use of an I-Frame approach or by adding a link to the Navigation Pane. Although there are cases where the I-Frame approach is justified, generally the Navigation Pane approach is better as it is more visually appealing and provides better use of the screen real estate.

There are many applications for this type of integration:

• It can be used to pull relevant information from a web page (msn, google, yahoo etc.) and have it presented to the user when they access an account. 
• It can also be used to accomplish virtual integration with another business application. For example, instead of physically bringing over invoice data from your back end accounting system into CRM for access via your front office, you could integrate the applications virtually by means of this approach. 
• You could integrate reports into a form to provide graphical, summary or other displays of information that cannot be achieved through other means. Alternatively if say your accounting data, is not accessible via URL, you could create an SRS report on the data you wish to view and combine it with your CRM form.

Below is an example of the first of these i.e. a mash-up between a CRM account and a Google map. The map is context sensitive to the address of the account and when the "Map" link is clicked it will show the address of the account on the map. The same is true for the News and Stock links shown in the screenshot.

You can download the files and instructions for configuring this in the Navigation Pane in the 4.0 environment from here.

Outlook CRM contact not showing with a CRM icon

We encountered the scenario where a contact that was clearly marked as a synced CRM contact was not showing in the Outlook client with the CRM icon,

We discovered the reason for this. In this case the client wanted centralized contact management. Meaning they did not want the ability for any of the end users to be able to update the contact record other than through a central admin user to protect the integrity of the contact data. They were not satisfied with data audit or alternative workflow/notification options.

And in addition they also wanted the ability to have the contacts be synced with the end users' Outlook clients. Since there is nothing preventing a contact from being updated in Outlook via the end users, we had to prevent any contact updates from hitting the CRM server during the syncing process by removing the contact update privileges from these end users.

And therein lay the problem with the contact icon. The following is a scenario where a CRM contact in Outlook can have it's contact icon flip back and forth between the standard Outlook contact icon and the CRM contact icon:

1. The Outlook client user actually updated one of the CRM contacts in Outlook. 
2. During syncing the user would first get a permission error (that can be ignored) and then the icon would change to a standard Outlook contact icon (as the sync process would presumably think that since the contact can no longer be updated that the contact is no longer a CRM contact).
3. The icon will remain a standard Outlook icon until a change is made again to the contact on the Web client at which time the change would be synchronized to the Outlook client and the contact icon would update again. Note that a duplicate contact would not be created since even though the contact was no longer showing as a CRM contact in Outlook, the CRM contact GUID wherein the actual link to the CRM server contact is housed, would remain intact and hence the sync process could still locate the contact record in the client.

Why the CRM contact icon is therefore not determined by the presence or absence of the CRM contact GUID is beyond me... Sigh. Anyway, this is presently a program "feature" in CRM 4.0. I have not tested this function in CRM 2011 yet.

There are still open activities associated with this case...

Another one for the penny series...

CRM prevents cases from being closed as long as their are open activities against the case. If you attempt to close the case when there are open activities you will be presented with an error message as shown below:

Ok. So I can understand that you may want to warn the user of such an event before allowing the case to be closed... But forcing the user to close all activities prior to closing is perhaps going a little too far.

This is especially exacerbating when dealing with "unexpected" activities. For example, if an email notification fails to get sent for whatever reason, it will sit in the open activities with a status of Failed. And you guessed it - if a user tries to close this case they will be prevented from doing so. So even if I could accept a blanket requirement that open activities need to be closed before being able to close the case, I'd really have to draw the line to suggest that somehow a Failed email message is considered to be "open"...

Unfortunately this issue has not been addressed in CRM 2011 either.

The good news is that there is a solution to such a predicament. The following link has a good write up of this issue and even better - there is a plugin that can be downloaded that will resolve it altogether. Great job!

http://blogs.msdn.com/b/ukcrm/archive/2009/07/04/closing-an-incident-case-that-has-open-activities.aspx