Microsoft CRM 2011 Track vs. Set Regarding

The question often arises in product demonstrations and when engaging with new clients as to the distinction between the "Track" vs. "Set Regarding" options for promoting emails to CRM (or any other type of activity for that matter i.e. appointments and tasks).

The short and obvious answer is of course that "Track" is a quick way to just promote the email into CRM without further classification (it can of course be classified later); whereas "Set Regarding" not only promotes the email to CRM but also classifies it to the appropriate account, contact, opportunity, case etc. at the same time.

As it is unlikely (in the real world that is) that an individual would later go and reclassify something that was promoted earlier, it is generally best practice to use the "Set Regarding" option to classify immediately so as to satisfy the "if-not-now, when?" dictum. And given that the CRM 2011 Outlook Client has now made it that much easier to use the "Set Regarding" option by maintaining a "recent" list of associated entities (see screenshot above) chances are that the time required to click Set Regarding vs. the single-click Track option is going to be anyway minimal, thereby reinforcing the aforementioned general best practice.

However what if I just want to promote and classify an email to the contact that sent me the email? It seems kind of silly to have classify the email to the contact that sent me the email by using "Set Regarding" since the email already is implicitly classified by the "From" email address that it was sent from (or "To", "Cc", "Bcc"). Shouldn't it auto-classify and not require me to reclassify again by using the "Set Regarding"? That would just seem like common sense, wouldn't it?

And fortunately the answer is that this is not only common sense but also how CRM will actually handle it. To understand, let's first analyze how CRM handles the email distribution list. It is important to note that the handling of the email distribution list is the same regardless of whether you use the "Track" or "Set Regarding" option so the next paragraph applies to both techniques.

In a nutshell, CRM will try and auto-resolve all the contacts on the email distribution list to a CRM contact, or user record. This is best illustrated by viewing it in the Microsoft Dynamics CRM panel below the email and also in the CRM email record itself after having click "View in CRM"

Microsoft Dynamics CRM Panel

View in CRM

If CRM, cannot resolve a contact from the distribution list, it will show as unresolved - but that is a topic for another time.

If CRM is able to successfully resolve the email to a contact record, the email will then appear in all the resolved contacts "Closed Activities".

Not only that, the email will also appear in parent "related regarding" roll-up views.

To re-iterate, all the above is performed as part of email resolution process regardless of whether you elected to use "Track" or "Set Regarding". Which therefore means that had you just used the "Track" option for the email, you still are able to have it be associated with the appropriate contact and parent account.

Therefore for emails (appointments and tasks) if your only requirement is to track the email to the corresponding contact record in CRM then selecting "Track" should be sufficient (assuming the contact exists - there are also options for auto-creating the contact if not, but that again is a topic for another discussion). In this scenario, using the "Set Regarding" is arguably redundant. However if you wanted to related the email to some other "less obvious" entity (case, opportunity, etc.), then you obviously would need to make use of the "Set Regarding" feature as per the aforementioned best practice.

CRM 2011 Update Rollup 5 form issues

As mentioned previously, CRM 2011 Update Rollup 5 in particular introduces some nice new improvements/enhancements. But also as mentioned this rollup cannot be uninstalled. Or technically it can be uninstalled by essentially uninstalling CRM 2011, restoring a database backup and re-installing CRM 2011 again along with the previous rollups to get back to where you started...

So knowing that this is the case, I came across a perplexing issue which appears to have been introduced by Update Rollup 5 that caused a form to no longer render correctly. The end result was that I was receiving the fairly generic "Error on page" message and as indicated in a former post on the topic, the error seemed to occur even when jscript was disabled. And so - using the same process of elimination technique described in that post - I went about removing snippets of jscript until the root cause of the issue was discovered.

The issue came down to the application ribbon EnableRules in the particular case where the EnableRule references a custom function within the form jscript (as described here).This didn't really seem to make any sense but it was evidently the case as every time the function was removed, the form error went away and vice versa. Delving a little deeper it was determined that if the function was left in but one of the form global variables that was referenced was commented out, the form would once again render properly.

So the conclusion that was reached was as follows:

• Before rollup 5 it appears the form onload script was executed prior to executing the custom EnableRules functions defined in the application ribbon. This allowed for global form variables to be declared that a custom EnableRule jscript function could then reference.

• Post rollup 5 it appears that the load order was altered such that the form onload script no longer executes prior to the execution of application ribbon EnableRules functions. This means that any global variables referenced in a custom EnableRule jscript function are undefined and will result in the form error described above.

That's at least what I deduced from the behavior that I observed. This issue was reported to Microsoft but rather than waiting for a resolution (which could take a while) or trying to painstakingly revert to a previous rollup, I implemented a workaround solution which was to essentially do away with the form global variable and rather recalculate the value in the EnableRule custom function itself. Once implemented in this way, the form was happy again.

Needless to say the above issue was perplexing indeed - you know the feeling - where you start second guessing your own sanity... So if you encounter such behavior after installing the above rollup, you may want to look into this as one of the potential reasons for the strange form behavior.

CRM 2011 Document Management Settings: Based on Entity Pros/Cons

It's been a little while but in a former post we were discussing the various configuration options that we have available when configuring the out of the box SharePoint integration with CRM 2011. And in particular, we were reviewing the impact that the "based on entity" setting has on how the content is physically stored in  SharePoint. Or as I termed it - "the centricity of storage".

I had also mentioned that we'd review the pros and cons of these configuration options and in this post I'd like to make good on that promise. In particular, I'd like to focus on the pros/cons of setting the "based on entity" to  Account or Contact. For the sake of discussion, we'll assume the Account-centric setting.


The benefit of this approach is that the content is a little bit more organized. That is, the structure of the content mirrors the structure of the customer organization and therefore it seems more logically organized to a certain extent. For example, if you had a customer portal that exposes customer documentation, it would be sufficient to link it at the account level and the remaining levels would just “follow suit”.

The main downside of this approach is that it can become more disorganized over time. Some of the contributing factors to this might be:

• Documents can be stored in different paths depending on the “characteristics” of the entity in question. For example, a contact with an account will be stored in the “..\account\SolarTech\Joe Bloggs” location, whereas a contact without a parent account will be stored in the “..\account\Joe Bloggs” location (as there is no account reference). This is perhaps the most unsettling factor as you want order to your data so that you can follow a logical predefined path for storing and retrieving data rather than having two different navigation systems depending on the nature of your data. This issue might be mitigated if the nature of the entity is such that it would always have a parent. For example, contacts in CRM could very well be parented or un-parented leading to the issue described. However opportunities should always have a parent and therefore is less prone to this type of disorganization.

• The relationship structure can change. For example (using the illustration provided in my former post), Joe Bloggs might at some point leave SolarTech and join ABC Corp. This is ok, but CRM is not yet smart enough to detect this change in relationship structure and it will be up to a diligent user (which is wishful thinking at best) to change the location under the contact rather than continuing to add content which will inevitably lead to the wrong documentation appearing under SolarTech.

• The “oops factor”. This is a variation of the above. That is, what happens if I create a contact, click on the Documents link to create the SharePoint location and then “remember” to associate a parent account to a contact? The result is that I now have the SharePoint location for this contact stored in the wrong path and as a user I need to remember to move this around. It is possible to mitigate this by creating some client side script. For example, we could hide the Documents link until an account is added but there are other scenarios that would be impossible to cover (e.g. initially parenting a contact with the wrong account). 

• Too many levels. It can also quite easily be argued that the account-centric approach introduces too many levels into the document storage structure, involving too much required navigation etc.

Next: We will need to review the pros/cons of the "individual" path approach and see if we can perhaps bring it all together by driving towards a best practice recommendation.

Lync Presence in CRM Outlook Client

My previous post highlighted some of the enhancements that Update Rollup 5 has brought to the table.


The last one on that list - CRM Outlook Client enhancements - includes fixing a pet peeve that was noticeably absent until now. Which was the lack of an integrated Lync presence on the CRM Outlook Client. This seemed to be a glaring oversight as it did work in CRM 4.0. We had logged this as a support ticket to Microsoft and the response we received was none too encouraging and I quote:

Thank you for your patience, I wanted to give an update on this.  Our Escalation Engineers have determined that this is functioning by design and will not get fixed in the current release of CRM.  This functionality worked within CRM 4.0 client because CRM data was display on web pages which allowed presence data to be displayed.  In CRM 2011, our development team opted to give CRM more of an integrated look and feel with Office, so standard Outlook controls were used.  As a result, the control in which CRM uses to display data does not support the usage of presence data.   

To implement functionality to include presence data within Outlook would require a redesign of how the CRM client displays data.  Such a redesign will not come in the middle of a product lifecycle but it certainly is possible for a future release of CRM.  Please feel free to submit this as a product suggestion to our developers at https://connect.microsoft.com/dynamicssuggestions/

Let me know if you have any remaining questions on this issue.  If you do not, I will go ahead and archive this support incident.

Anyway, this story of course has a happy ending. The support rep indicated that the enhancements would be possible in a future release of CRM. When he said that I assumed that it would be pushed out, at a minimum, to the next major release of CRM. But I guess it depends on how you define "release" and in this case it seems to be that Update Rollup is classified as a release. Either that or Microsoft development changed their mind but either way I'm not complaining.

Below is a screenshot illustrating the user experience (I couldn't get anyone else to pose so you'll have to settle for an image of moi).

CRM 2011 Update Rollup 4 and Update Rollup 5 cannot be uninstalled

In case you miss the small print that accompany both Update Rollup 4 and Update Rollup 5 you should note that neither of these updates can be uninstalled due to the significant changes they make to the database. So you definitely want to perform a database backup before installing and perform the necessary testing in a test environment before applying to production.

So what are the significant enhancements/improvements that prevent uninstalling? While Update Rollup 4 seemed to mainly focus on some performance improvements, Update Rollup 5 has a slew of improvements including:

• Chart Design Enhancements
• Dialog/Workflow Enhancements
• Enhanced Data Management
• CRM Outlook Client enhancements 

Not too shabby indeed.

Microsoft Dynamics CRM 2011 Downloads

It might be my imagination but it seems that Microsoft has moved the download locations for the Microsoft Dynamics CRM server products. It used to be that if I needed to download these products I'd just do a Bing or Google search for "Download Microsoft Dynamics CRM 2011" or thereabouts and the link for the the CRM downloads would appear at the top of the list.

Well I thought that perhaps I was going crazy but I could no longer find the download page. I tried a number of search criteria variations in the various search engines but I'd get results of all things Dynamics CRM (not to mention several broken links) except the blessed server downloads that I was looking for...

I'm sure the search engines will catch up with this re-org (you would think that Bing would have been automatic...) but in the meantime you can use the links below (I eventually found these by searching directly on Microsoft's download site):

• CRM Server
• Email Router
• Report Extensions - Install using the SrsDataConnector folder under the CRM Server server download

Where did my Outlook reminders go?

If like me you've suddenly noticed that Outlook reminders for tasks, appointments etc. are no longer appearing (hopefully not as a result of having missed an important meeting or such like), then you may want to read on.

 

This issue occurs for Outlook 2010 and it appears to have not been fixed in the Outlook Rollups. But you may want to install the latest rollup (UR5 as of this writing) before going any further.

The cause of the issue is highlighted in KB article 2584053.

You can download the hotfix from here. It goes without saying that you should select the correct version (if using IE it should auto detect that for you), and then follow the instructions to have the fix emailed to you.

After installing, create a test reminder that is in the past to ensure that it comes up as soon as you have entered it to ensure that this has indeed fixed your issue.

Uploading files from the file server using Scribe

The Challenge
You need to upload files from a file server into CRM. A good example of this requirement might be if you're migrating from another CRM system where attachments to CRM entities are stored directly on the file system and referenced from the CRM records rather than being stored as a blob directly in the database as is the case with Microsoft Dynamics CRM. When a file is already stored as a blob in the database, the conversion is fairly straight forward. But how do you about uploading files that are stored on the file server as attachments to MSCRM records?



The Solution
Fortunately the solution is also pretty straight forward if you have the option of using Scribe for migration. As a picture is worth a thousand words, I will illustrate it with a screenshot:

In short, all you need to do is to map to the "annotation" entity and ensure that:

• isdocument = 1
• vfAttachmentFileName = path of the file on the file server

And that should pretty much do the trick.

There is a problem communicating with the Microsoft Dynamics CRM Server

We received this error while trying to configure the CRM Outlook Client for CRM 2011:

This was from a machine where we were able to connect to CRM 2011 using Internet Explorer so it was a little perplexing why we should be receiving a communication error as indicated in the error message issued above.

In order to resolve, the following steps were taken:

1. Enabled Tracing by going to Start | Microsoft Dynamics CRM | Troubleshooting tab and enabled tracing
2. After reproducing the error retrieve the trace files from %Userprofile% \Local Settings\Application Data\Microsoft\MSCRM\Traces
3. Analyzed the trace file to find the source of the error

It turns out that in our case there was an errant plugin that was causing the error as indicated in the logs:

In this case, we had upgraded from CRM 4.0 and although the plugin above still worked (using IE navigation), it apparently was troubling the CRM Outlook Client for reasons that are not entirely understood. Anyway, disabling/removing the plugin resolved the CRM connection error that we were experiencing.

In conclusion, it turns out of course that the error message itself was a little misleading because as we discovered - the issue was related to a wayward plugin rather than connectivity.

What happened to DeletionStateCode?

DeletionStateCode is no longer in CRM 2011. The following post provides a good history and reasons for deleting the DeletionStateCode field.

Obviously the implication of removing this field is that now when a delete operation is performed it is a lot more permanent. You can no longer quickly go behind the scenes and run a script to retrieve the deleted entry (or entries as cascading rules might take effect). Not that you ever should have taken the action of deleting lightly, but now you will want to be that much more sure when you are faced with the "Are you sure you want to delete the [entity], including all records under the [entity]" prompt...

If you have auditing enabled for the entity in question, you will be able to see the entity with all its attributes along with any audited sub-entities and all their attributes so information in this case is not lost and you could painstakingly recreate the entity from this log. However there's a big caveat in the above i.e. the assumption that the entity in question and all sub-entities are being audited (which is quite a big assumption especially on the sub entities which can vary per delete operation). The image below shows the Audit Summary View of a deleted account entity along with the child contact entity - as illustrated, the details could be reconstructed.

If the entity is not being audited then the only way to retrieve the deleted record(s) would be via a database restore operation and some SQL queries to retrieve the data (assuming you didn't want to restore the entire database on top of the production version).

In spite of this, I view the removal of the DeletionStateCode in a positive light. The question arises - how many layers of protection is required to prevent the user from deleting something that should not be deleted? Here is what we already have:

• Warning - The "Are you sure" prompt making users think twice before confirming the action they wish to perform
• Record Status - We already have the active vs. deactivated record status. A deactivated record is in a sense a deleted record i.e. it is removed from all active views. When in doubt users should deactivate rather than delete.
• Permissions - The availability of the delete action is controlled via permissions. Best practice recommendations are generally not to provide end users with delete permissions for sensitive data. 
• Audit - As mentioned above, the audit tool provides another line of defense for something that has already happened.

The Audit feature is new in CRM 2011 and perhaps this additional measure is what pushed Microsoft over the edge in terms of removing the DeletionStateCode. Whatever the underlying reasons might be - the benefits of the removing this field (as mentioned in the referenced post above) far outweigh the pitfalls.

As a last point, the impact to reports in a CRM deployment should be low. That is because CRM reports are meant to adhere to the CRM SDK, and such reports referenced the Filtered Views which anyway did not have this field in their definitions. If you are finding that your reports are failing as a result of this change, then that might be an indicator that your reports were not written adhering to the SDK standard which is something you may want to look into...