CRM 2013 Notes Control only showing notes

CRM 2013 has a handy new feature for displaying activities, notes, and posts in a single control. This is very easy to configure by just selecting the "Notes" control in the form designer.

You can subsequently also define the default view for this control in the properties. As an aside, it's also recommended to uncheck the "Display label on the form" check box as it will display better without this.

So far so good. Except for one small wrinkle - the "Activities" and "Posts" tabs for this control do not show...

I found a solution to this issue which is outlined in this blog post. Although it does appear to be an issue even for forms that have already been "upgraded". Case in point - the form that I was working with was a new form created in CRM 2013 for an existing entity and the issue still appeared.

Anyway, as described in that post, the issue is fixed by modifying FormPresentation node for the form in question from 0 to 1.

After importing and publishing, the 3 tabs for this control display as expected.

CRM 2013 Option Set Length

There are a few, let's say, particularities of the CRM 2013 UI experience. Some of them take getting a little getting used to such as the new way of navigating the system whereas others seem likely to be early release features that are destined to be "tweaked" in early product rollup releases... at least one would hope so!

A good example of this is the length of the drop down for option sets. Take for example, the following form:

As can be seen the drop down for the title is only showing two options at a time. Considering that there are at least 20 values in this option set, this experience is not likely to go down well with end users... and nor should it.

The way to get round this design issue is to add some spacers into the form as follows:

And after publishing, the form renders in a little bit more of a presentable fashion:

The downside is that when the option set is not in its drop down state there's a lot of unnecessary white space on the form.

So we have a workaround to this behavior but I find it to difficult to understand why it was designed in this way (maybe someone can enlighten me?). The way it worked in all previous versions seems much better and hopefully this will be rectified shortly (at which point we'll likely have to go through all those forms and remove the spacers which were added as a workaround - so hopefully sooner rather than later).

Read only URLs cannot be opened

There is this annoying little issue whereby read only URLs on a CRM form cannot be opened. There really seems to be no rhyme or reason for such behavior as a URL by definition takes the user out of the context of the form and therefore I cannot fathom why such an action should be prevented.

The alternative is to make the field editable but that might not be an attractive alternative especially if you do not want this field to be updated!

I came across an interesting solution for this whereby you can keep the field editable but just remove the option of, ...well..., editing the field. To me it just seems like a different way of making a field read only that doesn't suppress the ability to open the link. And that works for me...

To do so, leave the field editable on the form and place the following line in you onload form jscript:

document.all.websiteurl.contentEditable = "false";

Replace "websiteurl" with the URL field you are working. The result is that the field appears editable on the form but if you try and edit, you will not be able to. Double clicking on the field will launch the URL specified.

I do not think this is supported script so use discretion in applying.

Pending Update Contact Icon

After installing the CRM Outlook client you will have no doubt have noticed the CRM icon that gets associated to CRM contacts, emails, appointments etc. which is very useful to be able to determine visually that the record in question is in fact linked to CRM.

However you may have also noticed a contact icon that looks somewhat similar to the regular contact icon except that it has a little dot (clock?) in the bottom right hand corner. At first you may not even notice it but subconciously it will probably nag at you where you may feel that something seems amiss but you can't quite put your finger on it. Well that's kind of what happened to me....

... until I determined that in fact it was a distinct contact icon from the default contact icon. But then I was wondering whether it was CRM related or perhaps just something that I hadn't noticed before in Outlook. It certainly doesn't seem to have the appearance of being CRM related so initially I attributed it to something that I hadn't noticed before as part of Outlook behavior. But then the nagging question was - what did this similar-but-different icon denote? After all, there must be a reason for this variation...

In the end, it turns out that this in fact related to CRM. After you have made an update to a CRM contact and that update has not yet been synced to CRM, the contact will show with this icon. And once synced it will of course revert back to the standard CRM icon. So this icon indicates that limbo period between update and server sync. And I guess that little dot is indeed meant to be a clock...

Why this icon shows as a standard Outlook contact icon with a minor variation rather than the CRM Outlook icon with a minor variation (as it is very much still a CRM contact and it would be much clearer if it was depicted in this way) is a little beyond my understanding... But at least I now know what it means.

CRM 2011: Cannot unregister PlugIn

After having upgraded a CRM 4.0 installation to CRM 2011 I was attempting to unregister some of the plugins that were carried over from the 4.0 installation as part of the upgrade process. Yet whenever I tried to do so, I encountered an error telling me that the plugin could not be unregistered. The Error Message received was similar to the one shown below:

After a little bit of research, I discovered that the said plugin was actually a plugin that was developed way back using the CRM 3.0 plugin architecture and therefore had DLLs etc. in the "server\bin\assembly" sub-folder of the existing 4.0 environment being upgraded.

Once the files had been copied over to the corresponding sub-folder in the CRM 2011 upgrade environment, I was able to unregister the plugin successfully.

Not entirely sure that it makes sense in CRM 2011 to have to copy these DLLs present in order to unregister the plugin, but then again, I'm not sure it's worth spending any more time thinking about either.

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.

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

You must enter a number between 200,000 and 2,147,483,646

When entering a picklist value you may be presented with this error message:

This is a pretty well known issue and anyone who has been working with CRM for even a short while is likely to have encountered it. The solution is fortunately equally simple and presented at the bottom of this post.

With the advent of CRM 4.0, it was possible to not only overwrite a picklist Label but also the associated picklist Value. This gave much needed configuration options to the person configuring CRM but it also introduced a risk in that a user could change a picklist value to overwrite a value that is referenced in the database thereby losing that reference. And indeed if you try to do so you will be presented with the following warning:

But for whatever reason Microsoft decided to give the customizers of Microsoft CRM the option for configuration in this case along with the responsibility for taking such a design decision. This is a good thing. 

The caveat is that the above works for custom picklist attributes that you might create. For some reason when it comes to out of the box attributes, Microsoft suddenly seems to have gotten cold feet. Because in this case you are not able to create a new picklist value with a Value of less than 200000. So here we have a case where Microsoft giveth and Microsoft taketh away...

I am not entirely sure what the rational was for such a limitation but I can only surmise that it was guided by the following thinking:

• Protect against over-writing existing system values which could be used by the application (now or in the future)
• Have a clear differentiation between values that came with the out of the box configuration and values configured during a customer deployment

You may ask - what's the difference? The picklist Value is anyway completely behind the scenes and therefore what do I care if it's value is 15 or 1500? As long as I see the correct Label that's all that should matter. And for the most part and likely in most cases this thought process would be correct.

But consider the case where you have an integration between your CRM deployment and another internal or 3rd party application. If you are integrating the picklist value between a similar drop down/picklist in the other application wouldn't it be easier and more straight forward and make long term maintenance that much simpler if the numbers were the same? Of course it's not difficult to create a cross reference to map these values during integration but that takes the solution just a little further from "simple" than it needs to be. And therein lies the crux of the issue of limiting the configuration option and not entrusting the responsibility of such a design decision to the system customizer.

I for one would like to see additional optional attributes on the picklist attributes (or Option Set as referred to in CRM 2011) which would give additional options for integration mapping purposes which hopefully Microsoft will introduce in the not too distant future.

Happily in CRM 2011, it seems that Microsoft realized the limitations that they had imposed on those who really want additional configuration options and no longer imposed this via the front end.... or perhaps they realized that those who wanted to have this kind of freedom were not deterred by the front end limitation and instead took the back door configuration option as described here (for CRM 4.0):

1. Export the entity in question. For example to export accounts navigate to Customizations | Export Customization | Account | Export Selected Customization
2. Search for the attribute in question (e.g. accountclassification code)
3. Manually add a new picklist option as shown below
4. Import the entity and publish 

Infinite Loop Detection

This may be another candidate for the "if I had a penny..." series. It's not a new item but I've come across it enough times that I thought I'd bring attention to it.

Microsoft implemented an "infinite loop detection" mechanism within the workflow process. For example, it's possible for you to design "Workflow 1" that calls "Workflow 2" and then "Workflow 2" calls "Workflow 1" again, such that the workflow - once initiated will theoretically never end. And if these workflows are designed to call each other within moments of being initiated, things could potentially spiral out of control. And it is presumably for this scenario that Microsoft implemented it's "Infinite Loop Detection" mechanism.

You will have encountered this error when you open up a failed workflow and find the "workflow job was canceled because the workflow that started it included an infinite loop" message.

According to literature I've read on this topic, this error only occurs when  "a workflow calls itself (on the same entity) more than 7 times in an hour, the 8th instance will fail with the error..."

While in principle this may be a good mechanism, there are times when it gets in the way of good design. In fact, it can be argued that Microsoft puts such mechanisms into place as the lowest common denominator. Meaning that as Microsoft CRM is essentially a product that is designed for the masses and therefore there is no guarantee that those who "configure" CRM will be responsible enough to make wise decisions. In fact, CRM greatest strength could also - in the wrong hands - be its greatest weakness. That is, the application is so easy to customize/configure that you certainly do not have to be highly trained or technically qualified consultant in order to configure the system. But in the inimitable words of Spiderman: "with great power comes great responsibility". And therein lies the risk because when it comes to system design it is the THINKING - both short and long term - that is paramount. And therefore beyond the capability of being able to perform configuration/customizations on the system it is crucial to know when to add a new attributes, vs. entity, vs. relationship etc. etc. This topic clearly requires further development - perhaps for another time - but I digress, time to reel it in...

The point is that Microsoft - who knows that the product will equally be at the mercy of both the talented and not so talented (when it comes to technology) and that it's impossible to control who will have the keys to the kingdom at any given moment - has put in controls to protect the people from themselves. And this is but one example (another much better example is Microsoft's strict policy of not allowing direct updates to the CRM database - definitely a topic for another time).

Back to the issue at hand - it is perfectly good design to have multiple workflows calling each other. In fact, it could even be a recommended due to the modularity of such a design approach. But yet, if you do so you may hit up against this issue even though your human decision making skills are better than that of a computer in terms of detecting infinite loops - at least in this case.

And the "penny moment" here is - why didn't Microsoft recognize this might happen and give the end user the ability to override the behavior either through a global setting or through a specific workflow setting? Maybe this has been implemented in a different way in CRM 2011 - I haven't had a chance to check. Anyone?

In this case, the absence of such a setting is not that critical as I think the likelihood is that encountering this error is likely to be the result of testing rather than something that would occur in the real world. Because in the real world it is probably unlikely that you'd want to process more than 7 workflow steps in an hour. At least in theory, but even encountering this error in a test environment can be a pain.

Although there apparently is no setting to override this behavior, there is an ability to increase the threshold from 8 as described in this article. I am not sure if there is an upper limit - I remember at one point trying to increase it but still being dogged by the issue at an upper limit. If there's no upper limit, then indeed setting this threshold to a very high number would give a way to override this setting in which case I don't get my penny...

Auto assign via URL

We were faced with the challenge of being able to auto assign a record as soon as a user clicks on an email containing a link to the record:

I am sure that there is more than one way to accomplish this but the challenge was to differentiate between a user opening the record using the URL from the email versus opening the ticket from standard UI navigation (in which case we would want to suppress the auto-assign functionality).

The best way to achieve this seemed to be by adding a custom URL parameter that we could then manipulate via jscript to perform the necessary processing. However by default if you try and add custom parameters, the form will error out when you try and load.

Luckily, I discovered a blog entry which explained how to go about enabling the feature in the application. Believe it or not, you have to add a registry setting in order to allow this. I am not sure why there would be reason to suppress this in the first place but then again - if I had penny for every time I've wondered why certain features were designed in certain ways (MSCRM and beyond)...

Once this setting was in place, I could then add a URL via workflow containing the custom parameter:

And bob's your uncle! Well almost - of course you need to design the jscript on the form to retrieve the URL parameter (use the code snippet from the referenced blog) and perform the necessary logic to apply the update.