Dynamics CRM: On-demand or on-premises? Consider your reporting requirements

Companies willing to implement Dynamics CRM 2011 must decide whether to deploy it in their own infrastructure (on-premises) or to implement it at Microsoft’s dynamics.com cloud offering (on-demand). Normally people consider that both solutions go on-pair with each-other and that the bottom line decision should be based on cost.

There is however a tiny caveat that if not considered, can become quite a nuisance: Reports. Read more >>

Dynamics CRM: Odd behaviour in grouped charts with multiple series

Earlier this year, I bumped into an odd behaviour in Dynamics CRM 2011, which has been recently confirmed by Microsoft to be a bug. This has been the first bug I found in Dynamics CRM 2011 and I was hoping it would be the last since I wasn’t proactively hunting for bugs. Then I came across another odd behaviour, which has been flagged by my users.

The issue concerns the dynamic filtering of list views not behaving as expected when interacting with grouped charts containing multiple series. However this one Microsoft insists it is by design. I’d like to see what others have to say about it, though.

The odd behaviour I am referring to is quite evident when viewing opportunities. In order to replicate this issue, make sure you have lots of opportunities marked as open and closed (some as won and some as lost) and for more than one owner. Read more >>

Dynamics CRM: Teams Vs Queues

Looking into my bookmarks I came across an old forum post about when to use Teams or Queues for assigning activities. AniMandal from XRM Adventures blog came to the rescue providing an insightful answer on how and when to assign activities to teams, queues or directly to a specific user.

You can find the answer on Microsoft’s Dynamics CRM forum here.

Dynamics CRM: Adding a Country/Region option set using ISO 3166-1

In Dynamics CRM, there is one particular bit that I always find myself customising, no matter the client size, region or industry: Country/Region fields.

By default in Dynamics CRM the country/region field is a text field, which means users could type anything they want. This of course can lead to confusion. The solution is to add an option set (a drop-down menu), which can be localised into multiple-languages. The problem is giving the values to the option sets. People often tend to give values starting from 1 to the options in alphabetical order (e.g.: 1 = Afghanistan; 2 = Åland Islands; […]). But this can often lead to issues as options are added or removed from the list.

What if I told you that I think I came up with the perfect solution, but that would mean that you should give specific values such as 4 for Afghanistan, 705 for Slovenia and 858 for Uruguay? I didn’t come up with these values out of a whim. They actually make a lot of sense. If you haven’t figured out the meaning of these values yet, read on for the explanation.

Dynamics CRM: Stepping into organisation management

One of the core concepts in Dynamics CRM concerning organisation management is Business Units. Business units are containers used to represent the business hierarchy, where the organisation created during the installation of Dynamics CRM is at the top (that is, the root business unit).

Business Units are similar to an organisational chart, but not quite the same. Combining with other organisational management settings such as sales territories and sites, this can lead to a lot of confusion, and I’ve seen a lot of implementations where business units haven’t been properly considered.

I wrote this post as a kick-start guide for those who are unsure on how to structure their organisation in Dynamics CRM. Read more >>

Dynamics CRM: Automating record names

In every application that makes use of a relational database in a multi-tier architecture, beyond the unique identifiers for records within a table, it is common practice to allow records to be named in a way that would help users easily retrieve the relevant records, be it by search or browsing. In Microsoft Dynamics CRM is no different. Accounts are named by the company name while opportunities are named by their topic, and so on.

Since the idea of naming records is for the identification and retrieval of records, it makes sense to me that users can name Accounts and Contacts to their liking. However, this isn’t the case for Goal records in my organisation.

When creating Goals, users can type anything they want in the name field, which could range from sensible names like “James W Revenue Goal for Q4/2011” to cryptic names like “JW Rev Q4/11”, or anything but professional, like “Show me the money”. Sure we could come up with a naming convention that users should follow. The problem, evidently, is making sure that users will follow it.

The objective of this post is to propose a step-by-step solution for the automatic naming of Goal records following a naming convention through the use of one Javascript.