Cannot delete reports

On occasion I have encountered an error while trying to delete reports from the CRM user interface. The specific error message being: "Error occurred while deleting an item from the report server":

The error details are as follows:

Unhandled Exception: System.ServiceModel.FaultException`1[[Microsoft.Xrm.Sdk.OrganizationServiceFault, Microsoft.Xrm.Sdk, Version=5.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35]]: System.Web.HttpUnhandledException: Microsoft Dynamics CRM has experienced an error. Reference number for administrators or support: #9B008CA6Detail:
<OrganizationServiceFault xmlns:i="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://schemas.microsoft.com/xrm/2011/Contracts">
  <ErrorCode>-2147220970</ErrorCode>
  <ErrorDetails xmlns:d2p1="http://schemas.datacontract.org/2004/07/System.Collections.Generic" />
  <Message>System.Web.HttpUnhandledException: Microsoft Dynamics CRM has experienced an error. Reference number for administrators or support: #9B008CA6</Message>
  <Timestamp>2012-07-26T08:26:48.1031182Z</Timestamp>
  <InnerFault>
    <ErrorCode>-2147187945</ErrorCode>
    <ErrorDetails xmlns:d3p1="http://schemas.datacontract.org/2004/07/System.Collections.Generic" />
    <Message>Error occurred while deleting an item from the report server.</Message>
    <Timestamp>2012-07-26T08:26:48.1031182Z</Timestamp>
    <InnerFault i:nil="true" />
    <TraceText i:nil="true" />
  </InnerFault>
  <TraceText i:nil="true" />
</OrganizationServiceFault>

The error seems to be caused by the fact that the report has lost its reference back to the reporting services report repository (i.e. CRM org folder under http://<server>/reports).

The easiest way to deal with this issue is to simply upload a working report definition into the errant report. And subsequently you should be able to perform the delete operation.

New Xrm.Utility Functions in Update Rollup 8

Apparently roll up 8 brought along with it 2 new client side Xrm.Utility scripting functions along with it. These functions are described in the MSDN blog posting.

The openEntityForm function seems interesting and would seem to replace the standard javascript "window.open" function specifically as it relates to opening CRM entity forms. So something that could have been previously achieved with the likes of this script:

window.open(Xrm.Page.context.getServerUrl() +
 "/sfa/conts/edit.aspx?id=" + Xrm.Page.getAttribute("primarycontactid").getValue()[0].id,
"MyWindow",
"toolbar=0,resizable=1,width=screen.width,height=screen.height");

Can now be achieved with a simpler and presumably cleaner (in terms of user experience):

Xrm.Utility.openEntityForm("contact", Xrm.Page.getAttribute("primarycontactid").getValue());

The more interesting aspect of this command is the ability to pass parameters when opening the form (probably more apropo to the create form). This probably lends itself to creating a "clone" action for every CRM form among other more obvious usages.

The second function (openWebResource) is less obvious in terms of its usefulness - at least to me at this juncture. Perhaps it can optimize the performance for opening a form by not having to specify all web resources in the form definition that the form might use during the course of its operation and you can then manually load a web resource in the jscript when it is necessary? I'd be interested to see what the various use cases for this script might be.

Time to experiment and find out...

CRM Live Purge

So you've successfully conducted your Dynamics Sure Step Proof of Concept and your customer has decided to pull the trigger and implement CRM. Congratulations. You now quickly transition into implementation mode and the first step you need to do is purge your pilot data from your CRM environment. Or... you've successfully migrated your CRM data but you discover through testing that some data was deficient and you need to purge and reimport. Whatever the scenario your requirement right now is that you need to purge your data.

What is the best way of going about this in a CRM Live environment?

Well, technically this post does not only cover CRM Online - it can address purging in any CRM environment. However the reason why I'm addressing the CRM Live environment is because you can of course only purge data via the front end, 3rd party tool (e.g. Scribe) or using some programmatic solution that leverages the CRM APIs.

... And of course you should be doing the same in any environment, but let's just say that pragmatism sometimes sets in. For example, the size of the data makes the purge exercise a very slow one. So while I'm not going to go into it there of course "unsupported" ways of purging a CRM database in an on premise environment that are a thousand times more efficient than going via the API.

Anyway, back to the issue at hand - how do we go about purging? There are a number of ways:

1. Programmatic - Create a small .Net application. This should be pretty straight forward but requires a coded solution and you could run into problems with timeouts for large data sets.
2. 3rd Party e.g. Scribe - Build DTS's to purge the data. Again quite straight forward but assumes you have access to such a tool
3. Front end - you can of course use CRM's front end. However going from entity view to entity view and deleting that way would be highly inefficient both because you are limited to 250 rows per deletion and because you'd need to remember to repeat the same steps each time - assuming you need to purge more than once. So a more efficient way is to use the Bulk Record Deletion Tool. The remainder of this post will discuss using the Bulk Record Deletion as a purge tool.

The benefit of using the Bulk Record Deletion tool is that it essentially documents the steps required for the purge and it can subsequently easily be re-used to perform subsequent data purges. Below are the steps required to facilitate this:

Use the Bulk Deletion Wizard to delete all records from the entity in question (or you can limit this to a subset of records you wish to purge by filtering appropriately). Repeat for each entity you wish to purge.

Name the job appropriately and set a recurrence for 365 days. If you do not set a recurrence you will not be able to reuse the job at a later point in time so this is set only to facilitate reuse.

Now all your purge jobs will appear under the "Recurring Bulk Deletion System Jobs" and when you want to re-run the purge you can highlight all your purge jobs and select More Actions | Modify Recurrence to re-run the jobs immediately.

NB: It goes without saying that you need to create a very conspicuous reminder to cancel your purge jobs once you have cutover to production or else you might be in for a nasty surprise down the line... Use responsibly and at your own discretion.

Simplifying Navigation: Site Map Changes

This post continues the "simplifying navigation" theme. As a brief recap, when it comes to navigation -  what might be intuitive to me might not be intuitive to a client using the system. In my experience "technology challenged" clients can get confused in surprising ways. One of those ways is by having too many navigation options. This might be what Microsoft would term the "power of choice" but often having too many choices can be a problem and should be curtailed.

As I mentioned in my opening post on this topic, keeping the CRM deployment "relevant" is axiomatic. And therefore making entities that are not relevant/used in a deployment "disappear" through the use of permission settings should always be done. I am not discussing that aspect in this post.

Rather I am referring to Site Map changes to eliminate some of the CRM areas.

Let me back up a little. Having the different navigation areas can be helpful, however as alluded to above, some clients might find the additional navigation "daunting". And this can of course be locked down by eliminating the other applications area by performing some simple manipulation of the Site Map. And users can subsequently access other areas of the application by configuing via the Options what areas they wish to appear in the Workplace. And the result is a simplified navigation that will look something like what's shown below.

This is not major rocket science of course but sometimes it's the small changes that can make the world of difference in a CRM deployment (or any technology for that matter). If you find that your users are "getting lost" you may want to consider simplifying the navigation as in this example.

Given that the Settings area has also disappeared (there's really no need to expose this area to the lay user), you might ask how we can navigate to that area of the application when administration or customization needs to be performed on the system - as changes to the Site Map or global in nature.

The answer to the above is to bookmark the other areas of the application so you can navigate directly to them. Here are some of these bookmarks:

• Administration: http://<server>/<org>/tools/Admin/admin.aspx
• Business Management: http://<server>/<org>/tools/business/business.aspx
• Customization: http://<server>/<org>/tools/systemcustomization/systemcustomization.aspx
• Data Management: http://<server>/<org>/tools/DataManagement/datamanagement.aspx
• Document Management: http://<server>/<org>/tools/documentmanagement/documentmanagement.aspx
• Product Catalog: http://<server>/<org>/tools/productcatalog/productcatalog.aspx
• System Jobs: http://<server>/<org>/tools/business/home_asyncoperation.aspx
• Templates: http://<server>/<org>/tools/templates/templates.aspx
• Audit: http://<server>/<org>/tools/audit/audit_area.aspx
• Reports: http://<server>/<org>/main.aspx?etn=report&extraqs=&pagetype=entitylist 

Simplifying Navigation: Home Icon

After having given a lengthy introduction on my philosophy as it relates to UI Navigation, I thought I'd open with perhaps the oddest scenario that deals with this subject.

As is well known, there have been some concerns being voiced about having too many popup windows when navigating CRM. In contrast, I have dealt with CRM applications that keep everything in a single web form. And there are pros and cons for both design approaches which I'm not going to delve into now. I'll just summarize and say that Internet Explorer browser technology has signficantly reduced the downside of CRM's pop-up windows approach. Namely the "Always open pop-ups in a new tab" of the "Tabbed Browser Settings" that keeps everything in a single IE session as illustrated below:

However as more and more tabs get opened things can start getting a little crowded and it can start to look like this:

And in one particular case, the client was getting lost in terms of navigation specifically in regards to being able to find the main CRM navigation window. They requested a kind of "home" feature which would close the main window and return them immediately to the main navigation instead.

After a bit of research I was able to accomplish this goal with a relatively simple solution:

• I added a "Home" icon to the forms (this can be done per form or globally via the global ribbon settings)
• When clicking this icon it performed the following 2 actions:
• Reload the main CRM navigation
• Close the current form

This action was carried out using a simple jscript function i.e.:

function NavHome() {
 window.open(Xrm.Page.context.getServerUrl(), "homecrm");
 Xrm.Page.ui.close();
}

This solution is definitely not for everyone and contains two inherent limitations:

1. After clicking "Home" for the first time, another main navigation will be opened. Upon subsequent clicks the main navigation opened previously will be re-used. This means that there will be 2 main navigation windows - the main navigation window loaded when CRM was first opened and the navigation window opened as a result of clicking "Home". The main navigation form is able to be re-used via the "Home" icon as we are giving a handle to the form being opened via the jscript (homecrm) and every time it is called, it will re-use the window with that handle. The issue is that I could not determine what handle Microsoft provides the main navigation when opened the "standard" way. I am sure there are some clever tricks around this issue such as modifying the URL for opening CRM - I haven't looked into that.
2. Whenever the main navigation is reloaded using the "Home" icon the navigation is reset. So for example, if whenever CRM loads it by defaults loads the contacts view and you have navigated to another CRM view in that form - when you click the "Home" icon again, the main navigation will return back to its default i.e. the contacts view in this example.

Other than the above which do not necessarily take away from what we're trying to accomplish in any meaningful way, it works pretty well. That said, I do expect continued improvement from Microsoft in terms of UI Navigation (as we saw significantly with the introduction of CRM 2011) so at some point this whole solution may no longer be relevant.

Simplifying Navigation: Thoughts

One of the key factors to a successful implementation (of anything) is to make navigation as simple and intuitive as possible to the end users. Or to perhaps put it another way - confusion is the enemy and should be avoided at all costs. This is not to say that the default navigation of Dynamics CRM is unintuitive - in fact I would argue that the opposite is in fact the case. However there are many different levels of end users of Dynamics CRM and this often depends on the kind of market vertical it is being applied to.

For example, if CRM is deployed into a Professional Services organizations the end users are likely to be very computer literate and will likely take to adopting CRM like a duck to water and may even curtail substantial simplification of the UI so that they can navigate the application as they see fit (which may vary from end to end user - a practice which I personally don't encourage but certainly won't stand in the way of).

On the flip side, if CRM is deployed into a Financial Services organization the end users are likely to be much less computer literate. And any additional "options" for navigation that I personally may think are quite intuitive may in fact herald the unwanted "confusion" bogeyman.

Therefore - returning to my earlier statement - what I personally may think about the relative intuitiveness of the application is irrelevant. I need to be able to try and view it through the end users who will ultimately be navigating the application and responsible for the success of that deployment. And consequently it is crucial to take into account and understand what the level of the typical end user is going to be when it comes to configuring the end user interface.

Bottom line - if in fact your typical end user in a CRM deployment is the type that is on the "technology challenged" sector of society, then you'd better ensure that your CRM is locked down to a certain extent limiting navigation to the minimum in order to be able to do what needs to get done.

That all being said, I do believe that there are certain universal truths when it comes to the deployment of the UI navigation:

• Keep it relevant - For example, if a client does not use invoices in their CRM deployment, then make sure they don't see the invoices navigation option.
• Permissions - Ensure users only see what they should and nothing more.
• Simplify - Do not over complicate when it comes to design. Balance the "purist" relational approach with realistic scenarios in terms of how users will actually use the system (a key metric for this is the number of clicks involved in a particular action)
• Walkthroughs - Prepare walkthrough documents that users can reference for a particular function
• Training - Obviously provide the necessary training

In the next series of posts I will attempt to highlight some of the more novel UI navigation simplification ideas that I've experimented with.

Cannot open entity customization form

We were experiencing an issue whereby we could not modify the contact entity web form. Every time we'd try and open up the form editor, the following error message would be issued:

A little bit more information was revealed after turning on DevErrors:

Not sure how this issue came about but I imagine it's likely only to occur in an upgraded environment. Away, after a bit of digging I came across the following article which seemed to describe the same problem (albeit for the lead form):

http://blogs.msdn.com/b/atif/archive/2012/01/22/unable-to-open-lead-entity-form-in-crm-2011.aspx

So I decided to export my contact entity and perform a search on all cases where "rowspan" has a value greater than 1 (e.g. rowspan="4"). I came across 6 cases and in each case I performed a count of the row elements and they matched up with the rowspan count. Until the very last one that is...

In short, the screenshot below is what I found.

The rowspan count equalled to 4 yet there was only one row element (the one containing the rowspan element). So I added in 3 additional row elements as shown in the highlighted text, imported the customization and published.

And just as advertised this resolved the issue.