January 2008 - Posts
-
-
Opinions differ on whether CRM is, can be, or should be an application platform. The points of contention are typically terminology and technology. Rather than focus on semantics, I want to focus on the possibilities the MS CRM application provides – based on my past experience. In addition to the term Application Platform, I have also heard Solution Platform, Development Platform, Application Framework, Solution Framework and Development Framework. I’m sure there are many more. We could debate why one term is more appropriate than another, but to me the objective is not the “term of the month”, but the ability of the tool; the ability of the tool to quickly and easily solve a business need. I realize quickly and easily are relative, but this blog is based on my opinion – from many years of developing, architecting and implementing custom solutions compared to designing and extending CRM. Rather than create another feature list of what CRM as a platform can provide, I will describe the possibilities through examples. Let’s start with a very simplistic example. Our example business need is for a “Suggestion Mailbox” application; a means to allow employees to record recommendations on how to improve the business and submit them to management for review. Five business requirements for this application are:
- Managers should be able to see all suggestions, users should only see suggestions they created.
- A suggestion needs to be related to a department, beginning with 3 options (HR, Finance & IT), however the ability to add more departments needs to be incorporated.
- When a suggestion is created, the manager from the department selected needs to be sent an email.
- Managers need to be able to set the status of a suggestion (New, In Review, Approved and Denied).
- When a manager changes the status of a suggestion to Approved or Denied, the user that created the suggestion should receive an email notifying them of the outcome.
These 5 business requirements imply many technology requirements including a robust security model, data management (including a database to store the information), workflow (to trigger and send emails), forms to view lists of records (users, departments, statuses, suggestions), forms to create and update records and more. The intent here is not to list every requirement in detail but rather highlight that a basic application still requires a lot of foundational functionality to exist in order to complete the application. This is where CRM as a platform steps in to give us a hand. CRM provides all of these foundational needs out of the box – meaning that time is spent on configuration of the business requirements and not on technical development. The configuration becomes defining the metadata to make up our new entity, security and processes. This consists of:
- Construct what a “Suggestion” is – what do we call it and what are its attributes (fields).
- Define security specifically for a “Suggestion”.
- Workflow needs to be configured to send the emails based on the requirements defined.
All of these can be completed through the standard configuration tools. To custom develop a working prototype of the “Suggestion Mailbox” ready for users to experiment with and test would take an experienced developer a few days to create (this is also assuming some reuse of existing code). However, creating this within CRM would take an experienced CRM admin or power user a couple of hours (including testing). These are just ballpark estimates for a very simplistic example, but the purpose is to show that CRM provides a lot more benefit out of the box than just Customer Relationship Management. It can become a platform for related and extended business processes.
As I wrap this post up, I would like to throw out some caveats. Do I think CRM should become the platform for all development and therefore companies should go out and purchase CRM for this purpose – no. Custom Development will always have its place and for some requirements it is the better choice. However, if you have MS CRM or are considering MS CRM I think you should consider and evaluate the business solutions it can provide from your Customer Relationship Management investment. In other words, if you have a development platform (or whatever term you prefer) that comes along with your CRM investment, why not take advantage of it.
In subsequent posts, I will discuss some real world examples to show more insight on the possibilities.
-
-
Like most developers, I am often the most frustrated by generic error message that never seem to give me enough information to solve the problem at hand. Because of this, and an funny situation that I went through while trying to publish a Plug-in with CRM 4.0, I thought that it might be nice to have a complete walkthrough of a simple Plug-in, from development to deployment. I have seen several blogs focusing on the code involved in writing a Plug-in, but not many on the deployment side, and this seems to be where the most issues occur.The following code is about as simple as a Plug-in gets. It runs on the PreCreate event of an Account (renamed Company in this installation), and generates an Account Number (int) for the Account in question. This sample is nearly identical to one included in the SDK.using System; using System.Collections.Generic;using System.Text;using Microsoft.Crm.Sdk;using Microsoft.Crm.SdkTypeProxy;namespace IS{ public class AccountPreCreate: IPlugin { public void Execute(IPluginExecutionContext context) { // Verify we have an entity to work with if (context.InputParameters.Properties.Contains("Target") && context.InputParameters.Properties["Target"] is DynamicEntity) { // Obtain the target business entity from the input parmameters. DynamicEntity entity = (DynamicEntity)context.InputParameters.Properties["Target"]; // Verify that the entity represents an account. if (entity.Name == EntityName.account.ToString()) { // Generate a new Account Number Random rndgen = new Random(); StringProperty accountNumber = new StringProperty("accountnumber", rndgen.Next().ToString()); entity.Properties.Add(accountNumber); } } } }}
Very simple. The only thing to remember is to include references to Microsoft.Crm.Sdk and Microsoft.Crm.Sdk.SdkTypeProxy in your project. These dll's are found in the bin folder, wherever you extracted the SDK to. Now that we have written our simple plugin, and verified that it builds without errors, we are ready to deploy using Microsoft's handy little tool, right? Wrong! This is where I had my problems, and they were a little embarrasing. New to CRM 4.0, all plug-in assemblies MUST be signed. This is a little security measure that Microsoft added. Signing code is really quite simple, but .Net developers seem to be divided into two camps. Those that sign everything, and those that have never signed an assembly in their lives. Unfortunately, if you do not sign your assembly it will register without errors but it will return a very generic error stating that the Plug-In was unable to be loaded. Because of this, the next section is for the latter group of developers who have never deemed it necessary to sign an assembly. In order to do this, all you need to do is right-click on your project, and select Properties.
.bmp "Project Properties")
After the Properties screen appears, select the Signing* tab, and in the dropdownbox select <New...>. Then a prompt will appear asking for a Key file name, and for a password. It is your option to password protect the key, if you do not want to, simply uncheck the box. Otherwise, add a password of your choice. .bmp "New Key")
Then save, and close the Properties window. You will now have a new file in your project. If you chose not to password protect it, the file will end in '.snk', otherwise it will end in '.pfx'.Now you are ready to publish the Plug-in. If you haven't already, build and deploy the Workflow Configuration tool that ships with the SDK. There are instructions on how to deploy this VS 2005 addin.To deploy your Plug-in, build the Project and copy the dll to the assembly folder in CRM, by default this is located at C:\Program Files\Microsoft Dynamics CRM\Server\bin\assembly. Then, while in Visual Studio 2005, select Tools --> CRM Plug-in Registration Tool. A screen will appear asking for connection credentials to your CRM installation. Enter them in, and click 'Get Connection':
.bmp "CRM Plug-In Registration Tool") Click the 'Assembly Registration' button. Here you will register the Assembly for CRM. Select the dll you copied into the CRM assembly folder earlier. Then select the Class that you wish to use in that dll. To the right, you will see an option to register to the Database or to Disk. For debugging purposes, I think that registering to Disk is best, while I like a Database registration for final deployment. After you have selected these options, select 'Register' on the right. A message will appear confirming the registry. You can also select 'Get Assemblies' to show all assemblies that have been registered to this CRM installation.
.bmp "Register Assembly")
Close the window, and select 'Step Registration' from the main window. From this new screen, you will tell CRM when to execute each method. Select your Assembly and PluginType from the drop downs. Then configure your options. For our purposes today, we want the Plug-in to work in Synchronous mode, Stage Pre, and Deployed only to the Server. The MessageName is 'Create' and the EntityName to work on is 'account'. Only out of the box entities appear in this list, but custom entities can be used by typing the schema name in the text box. After this is complete, click 'Register step on PluginType'. And you are done!
.bmp "Register Step")
Close all of the CRM Plugin Registration Tool windows, and launch CRM to see how it works.
-
-
This post describes a customization to CRM 4.0 which is not a supported by Microsoft, Crowe or me but something I needed to find a solution to given a client request. Please take this into account before attempting to make this change as in most situations you never want to update the CRM database tables directly. This may cause problems with upgrades and future releases. However, there are times when your users will demand a system change and you may be forced to take a bit of technical leap to make them happy.
Hiding system views in CRM 4.0 is one such area. For example, your implementation may not use the Marketing Campaign entities, and you wish to hide the “Contacts: No Campaign Activities in Last 3 Months” system view.
While there isn’t a clean way to do this currently using the standard configuration UI, you can force a system view to become a private view through a bit of direct database magic:
1. Navigate to the system view.
2. Make a change to the view, such as switching the column order. This will create a new record in the SavedQuery base table with the CustomizationLevel = 1. Customization = 0 records should never be touched since these are shared across mult-tenant organizations.
3. Publish the entity.
4. Find the view in the SavedQueryBase table. There may be several entries, so use the view with the CustomizationLevel equal to 1 that was created earlier.
5. Update the record and set the IsPrivate flag to 1.
UPDATE SavedQueryBase
SET IsPrivate = 1
WHERE [Name] = 'Contacts: No Campaign Activities in Last 3 Months'
AND CustomizationLevel = 1
Now once you navigate back to the entity, the view will no longer appear in the list.
Again, use the above SQL trick with caution. Manipulating the CRM database is not encouraged. However, since the functionality to hide system views existed in CRM 3.0, we felt this is something clients may have an interest in pursuing in order to meet the needs of their existing users.
-
-
We are back with a much improved blog! CRM 4.0 is out now which brings a lot of fodder for posts. Expect to see several new posts by members of the Crowe CRM Team on such topics as 3rd Party Add-ins/Applications, upgrading CRM 3.0 to 4.0, new 4.0 features, vertical CRM solutions and user adoption. Keep your eyes open for these posts.
During our down time, I reviewed all of our previous blog posts and realized that we were light on the business side. When we began this blog, our intent was to provide a well rounded blog with not only technical posts but also posts on the business aspect of CRM. I intend to correct this lack of balance starting with a series of posts discussing "CRM as a Platform". There are ranging opinions on whether CRM is or can be an application platform. These points of contention are based around terminology and the technical aspects of this. Rather than focus on semantics, I want to focus on the possibilities the CRM application provides - based on my actual experience.
Thank you for visting our blog and please come back often. Also, as always, please feel free to comment or contact us.
|
