Sonoma Partners Microsoft CRM and Salesforce Blog

Can’t Relate to your Charts?

Today's guest blogger is Peter Majer, a Senior Consultant at Sonoma Partners

CRM 2011 introduced some very powerful analytical tools including Charts and Dashboards.  With Charts (or Inline Visualizations) you’re able to quickly see a graphical representation of your current record set that’s being displayed in the grid.  You can also drill into components of your chart to slice and dice your data even further. Even better is that the record set in your grid is also updated as you drill in!

CRM 2011 comes with a set of standard charts out of the box for a handful of native entities (e.g., Accounts and Opportunities).  Even better is the fact that end users and administrators are able to create their own charts based on their security settings.  This allows users to define specific analytical charts they can share and use to quickly see a graphical representation of the data that’s important to them.

However, there’s a small limitation with building charts in CRM.  You can only display data from the current entity that you’re on, or from the primary attribute of lookup entities.  For example, if you’re interested in seeing a breakdown of your current open Opportunities Estimated Revenue by Account Industry, this isn’t possible using the native chart designer tools that CRM provides.  This is because Account Industry is a field on the parent Account, not on the Opportunity, and isn’t the primary attribute (Account Name is the primary attribute).

Luckily there’s a way around this.  It involves a little bit of knowledge of XML but not too much that you’d need a developer to complete this for you.  The overall approach is to create a chart using fields on the base entity, exporting it, updating the XML manually, and re-importing the chart back into CRM.  We’ll go into more detailed steps on how to accomplish this below.

In order to create the “Opportunity Est. Revenue by Account Industry” chart displaying data from the related Account entity, perform the following steps:

1. Create a New CRM Chart
First navigate to the entity you’re interested in building the chart off of.  In our example, this is Opportunity.  After you’re in Opportunities, you can click on Charts in the Ribbon, and then New Chart. 


2. Enter the Basic CRM Chart Details Using Fields on the Opportunity
In our example we’ll use the following settings for our basic Chart which will show Estimated Revenue by Potential Customer. 

Type = Pie
Legend Entries (Series) = Est. Revenue (Sum)
Horizontal (Category) Axis Labels = Potential Customer 


3. Save Your Chart
Now save your chart using the Save & Close button in the Chart Tools Design tab of the Ribbon.


4. Export Your Chart
The chart created above was a start, but we wanted to display Est. Revenue by the Industry of the Potential Customer (Account), not the Name.  Therefore we need to export it and modify the XML to get what we need.  To export your chart, click on the Charts tab of the Ribbon, and then click on Export Chart.


5. Open the Chart XML
Navigate to the XML that was exported above, and open it in any text editor.   You’ll notice something that looks like the following: 


6. Modify the Chart XML
The section of interest is the <attribute> nodes of the XML in the <fetch> section.  More specifically the one that has the Potential Customer field in it (customerid) is the one that needs to be updated.  Comment out this line by adding in the comment tags for XML at the beginning !-- and at the end -- of the node.  Those go between the begin and end carrots of the node. 


Now enter in the new XML right above the XML you just commented out: 
<link-entity name="account" from="accountid" to="customerid" link-type="outer">

       <attribute groupby="true" alias="_CRMAutoGen_groupby_column_Num_0" name="industrycode" />


In a nutshell, this is indicating to use a link-entity to join to the Account entity from the current entity (Opportunity).  The link is on the customerid attribute of the Opportunity linking to the accountid attribute of the Account.  Then, after that linkage is done using link-entity, you’re indicating to now use the industrycode attribute for your chart’s groupby.  The XML we commented out previously indicated the groupby was the customerid field which displays the Name of the Account (primary attribute).

In the end, your XML should look something similar to this:


7. Optional 3D Step
This step is optional and is another neat styling feature that is available with the CRM charts.  Again, this is available only by modifying the XML and not available by using the designer CRM provides you.

If you search the XML for Area3DStyle, you’ll see Enable3D=”false”.  You can update this to true, and save the document, and now you’ll see a fancier 3D chart when you import back into CRM. 


8. Import Your Chart
After saving the XML, you’re ready to import your chart.  In CRM you can go to the Charts tab of the Opportunity Ribbon, and select Import Chart.  Browse for your XML you just saved. 


9. Enjoy Your Chart!
After uploading the chart, you can now see your 3D chart that shows Opportunity Estimated Revenue by Account Industry.   


And that’s it!  You can apply the same steps above to create complex charts by modifying the XML that will create charts based on fields that you’re not able to create using CRM’s native designer.

Not that if you click on Edit Chart in the ribbon, you’ll see that it’s correctly showing you that your chart’s “Horizontal (Category) Axis Label” is the Industry field from the Potential Customer (Account).  


However, if you do end up changing this value and saving your chart, you won’t be able to change it back to this “non-primary-attribute” related field without going through the steps above to manually edit the XML.

Thanks to Jacob Cynamon-Murphy for assisting with finding out this trick with charts.



Topics: Microsoft Dynamics CRM Microsoft Dynamics CRM 2011

[INFOGRAPHIC] A/E/C Marketers: Stop Hunting for Content and Start Winning the Deal!

If you're a marketer and you work for an architecture, engineering, or construction firm - we know how painful it can be to generate a proposal. In fact, we know it so well, we made this infographic that shows how it's usually done and compares it with how it could be done if you used CRM technology from or Microsoft Dynamics CRM. 

(click image for a larger version)

Small infographicAEC_graphic

Bottom line? If you store project information centrally using CRM, generating proposals doesn't have to be such a wild and painful chase. 

Preparing your JavaScript for Cross-Browser Support

One of the most exciting features in the upcoming Q4 2012 Service Update is cross-browser support.  This will allow users to access CRM not only from Internet Explorer, but also from Chrome, Firefox, and Safari.  While this is great news, it is possible that custom JavaScript will stop working or cause an error when you upgrade.  It's worth pointing out that even if you do not plan on switching from Internet Explorer to one of the other browsers, you still need to update your code if it is from CRM 4.0 (see example 1).

The first step to making sure your code will still run after upgrading is to download the Custom Code Validation Tool.  This page contains a link to the validation tool at the bottom of the page, as well as detailed instructions on importing the tool into your CRM 2011 organization.

If you follow the instructions mentioned above, you will find yourself looking at a screen similar to this:


At the top left of the window is a list of all of the JavaScript and HTML Web Resources that exist in the current CRM organization.  When a file is highlighted, its contents are shown in the top pane, and a list of potential errors are shown in the bottom pane.  You can go down the list of all of your Web Resources and see if any of them have potential errors.

Everything up to this point has been pretty straightforward, and has not required any knowledge of JavaScript.  However, if you are going to be reviewing your JavaScript for potential errors, you will want to have a working knowledge of JavaScript.  The reason for this is because this tool won't tell you definitively what needs to be fixed and what doesn't.  Instead, it will flag potential errors that may not run correctly in the other browser.  In other words, just because the tool flags something doesn't necessarily mean it needs to be updated.  Let’s look at an example of code that does need to be updated, and then a false positive that doesn’t need to be modified.

Example 1


In this example, we have a function named disableLastName, that has two potential issues.  The first issue is the usage of crmForm.all.  A quick search for "javascript all collection" took me to this page, which says that the all collection is not supported by Firefox.  Even if you don't plan on using Firefox, it is still worth fixing because unlike Internet Explorer, the all collection does not exist on every HTML element in Chrome and Safari. 

The second potential issue is the use of the Disabled property.  This property is defined in an .htc file, which is an HTML Component file.  These files only work in Internet Explorer, which means they will be going away in the Q4 2012 Service Update.  Since .htc files won't be around anymore, the Disabled property will need to be replaced as well.

So how do we update this code?  If we take a look at the "Form Scripting Quick Reference" section in the Dynamice CRM SDK, there are two methods named Xrm.Page.getControl and setDisabled.  We can use these two methods to update the code to:


Because we are now going through the supported 2011 Xrm methods, this code is guaranteed to work in all supported browsers.

Example 2


In this example, we have a function named alertUserOnClick.  Imagine we have a custom HTML page, and we have a JavaScript function that will allow us to show the user an alert message any time a button is clicked.  As you can see, the tool has flagged the attachEvent method as a potential issue.  The reason this method was flagged is because attachEvent is only available in Internet Explorer.  However, if we look at the code, we can see we first check for the existence of the addEventListener method, which is the W3C standard method used to add an event listener to an HTML element.  If that method does exist, it will be used.  Only if the method doesn't exist do we fall back to the attachEvent method.  This is an example of the tool flagging a false positive.  Even though our code contains the attachEvent method, that section of code will only be executed when we are running Internet Explorer.

Unfortunately, it is impossible to go through every possible scenario of code that may or may not break.  Hopefully you now have a better idea of how to analyze your JavaScript for potentially breaking changes.  As I mentioned earlier, this is a task for someone who is familiar and comfortable with JavaScript, as this is a technical exercise and will require a working knowledge of the differences between the four browsers that CRM will support.

Topics: Microsoft Dynamics CRM