Dynamics CRM 2011 has some major improvements that make it easier to use, but sometimes you still need a custom solution. We’ll explore some tips and considerations for going custom with Dynamics CRM 2011.
Microsoft certainly made improvements with Dynamics CRM 2011. They introduced a much more flexible user interface when compared to previous versions, incorporated industry standards in user experience design, and gave the application a uniform look and feel. These changes make customization easy and brought CRM inline with Microsoft Office and other Dynamics products with a consistent end user experience. While CRM 2011 is highly customizable and provides many options for organizing and manipulating data to the user, the user interface has its limits and sometimes the best answer for user experience cannot be achieved.
A standard CRM entity form containing a large number of relationships and look-ups can easily become tedious and confusing to read and populate. Many times an organization may find that the only way to create the optimal end user experience is to build its own custom application to facilitate the process. Whatever reason you may have for choosing to go completely custom there are several important things to consider before jumping in.
As with all custom applications, you must first weigh the benefits of custom functionality against the costs of maintenance and the availability of specific skill sets and resources. Generally a non-technical administrator can configure and customize Dynamics CRM forms, however to build a custom .NET application which integrates with CRM you would need special skills and resource availability to build and maintain the application. A few maintenance items specific to integration with Dynamics CRM are the dependence on Active Directory Federation Services (ADFS), the use of version specific CRM SDK class libraries, the overhead of web service based communication, the use of early vs. late bound types, and certain limitations of the CRM SDK.
ADFS 2.0 Authentication
If your instance of CRM is Internet facing and relying on ADFS for claims based authentication, then your custom application will also need to rely on ADFS. When installing and configuring CRM the process of enabling Internet Facing Deployment (IFD) and claims authentication is fairly straightforward. The wizard guides you through the steps and a reasonably competent system administrator can make the necessary changes on the ADFS server to facilitate the authentication. However, when building your own custom .NET web application the process is a bit more complicated. You will need to configure your application in such a way that it can share authentication with CRM and authenticate the user on its own.
First you will need to use Visual Studio to add an Security Token Service (STS) reference to your web project. This wizard will guide you through a step by step process of gathering data so that Visual Studio can make the necessary changes to your web.config to support the redirection for ADFS authentication. Visual Studio will also create a FederationMetadata.xml file in your web project which ADFS will use when you configure the relying party trusts on the ADFS server. The second step is to write the necessary code in your web application to consume the ADFS authentication token and identify the user using the User Principal Name (UPN) from the execution thread. This is very different than what you had to do if you had previously used Windows Authentication in your web applications and pulled the user identity from the web context. Once you have the authenticated user’s UPN you can then make a call to the CRM Discovery service and retrieve that user’s CRM ID. Lastly you impersonate that user by setting the CallerId of the OrganizationServiceProxy and you are ready to start executing requests on that user’s behalf.
The final step to enable your custom .NET application for ADFS authentication is to create a Relying Party Trust using the ADFS Management Console and pointing it to your website’s FederationMetadata.xml. The ADFS Manager will collect the necessary connection information to create the trust. Lastly you must modify the trust by adding three rules that will either pass through or transform Active Directory information into a format that will be recognized by your claims aware application.
There are two important things to consider with this type of solution. As you probably surmised from the above description, the ADFS authentication adds a certain amount of overhead to each transaction which will play a role in the speed and performance of your application. Also this solution has limitations when it comes to using the CRM Client for Outlook. Authentication in Outlook operates inside the Outlook context only. So if you have a custom ribbon button that launches your new web application, the authentication from CRM will not carry over from Outlook and you will have to log into CRM, via ADFS, the first time you access your custom site.
Proceed with Caution
There are a few other very important things to consider when developing custom applications in Dynamics CRM. Like all good application development frameworks you have several options to consider when interacting with the CRM API.
Here are a few things to consider when designing your application:
If your application relies heavily on early bound types and other techniques which are dependent on the Dynamics CRM dlls, keep in mind that all of those dlls change version when a new rollup is released. So you must be diligent to update and test your code with each release.
There are significant limitations with FetchXML and QueryExpressions. In short, you cannot do everything you can do with SQL with FetchXML. For example, FetchXML cannot handle comparison across joined objects. So if you want to include in your “where” clause a condition on your main entity as well as one that you have joined to, there is no syntax to support that. There are also limitations on the number of records these queries will return that must be taken into consideration.
The Lync interface which was introduced with version 2011 is really cool and easy to use, however, it is extremely slow and unless done correctly, it can have significant performance impact not only on your custom application, but on the CRM server as well.
Although using early bound types will make the development process significantly easier, it may not always be the best option for your application. For example, we have found that when using plugins, it is best not to use early bound types due to the issues introduced by dll dependency. Early bound types also give your application a much larger footprint due to the size of the generated dll, so keep that in mind during your design.
Credera has extensive experience in deploying and customizing Dynamics CRM for our clients. We are always looking for opportunities to share our experiences and help companies through the difficult business and technical decisions that come with implementing a CRM product. For more information, please contact us at email@example.com and follow us on Twitter @CrederaMSFT.