So I am relatively new to the Dynamics CRM world. Previously, I worked at a medium-sized association (350,000 members) which is/was using TMAR’s Personify Association Management System to handle all their interactions and marketing. We customized it a great deal, and ended up in a very bad place (as in no upgrade path and a very ugly code base). As I have moved to Dynamics, I have found that while it is certainly a very capable system off the shelf, there are still instances where you will need to customize the solution to meet your business needs, which is true of just about any CRM product. So in the interest of helping other Dynamics newbies out there, I thought I would share a couple reminders that I found really helpful when making the mental shift to Dynamics and tracking down just how it’s all tied together. Hopefully it will help you keep these things in mind as you build out your system.
- Know Your Environment(s) – While this may seem like a no-brainer, I can’t tell you how many times I have tripped myself up from thinking that production and test environments are supposed to match when in fact the code is different. This becomes all the more true if you are starting out on an already exiting implementation with a well established deployment routine. Another part of this is don’t take people’s word for it. Unless you have had eyes on the code base to see that they are indeed the same, assume that they are not. So when you put together your back-ups and roll-back scripts, make sure they are generated from the appropriate environment. This becomes especially true if you have other systems that live side by side with your CRM instance. Often times you will have systems that live completely outside of CRM that you will be integrating in. Make sure you know where they live as well, and how the interact.
- How is Dynamics Being Used – While this may also seem fairly straight forward, often times (at least for me) I can get so focused on the “How” that I sometimes miss the “Why”. I can’t tell you how many times I have dived right only to find out that the way I expected something to work was not actually based on the business rules. Knowing how your business or client is using the system is probably right up there with knowing how the environment is set up. Taking the time to review not only any documentation, but to also work through the system making sure to familiarize yourself with how your users are experiencing the system will make a huge difference when it comes time to actually get into the code base and make changes.
- Seek Out Any Customizations – This is important. While I was helping maintain Personify’s system, we found that many of the custom process or code that we needed had been built into the core system instead of added as a module. This ended up killing any sort of upgrade we wanted to run on the core Personify system and made maintenance a nightmare. Dynamics allows for customizations, but does so through an internal interface. Under Settings > Customizations you will find a list of all of the various pieces and plugins that have been added to your instance of CRM. This central repository, while not always the only place customizations may live, is certainly a great place to start. Another thing to keep in mind, at least for any web hosted instances, is that you can have links or iframes on any page, meaning you could have custom sites that live outside of your CRM instance that may be contributing to it. In terms of practical advice one thing that was suggested to me (above and beyond what can be found here: http://msdn.microsoft.com/en-us/library/gg509027.aspx), was to make sure that you don’t need to continually search the DefaultSolution for your customizations. By making sure that your customizations live in their own solutions, you make maintaining the system a bit easier as well as keeping things compartmentalized. It also makes your solution that much more modular, allowing you to change out sections without affecting the rest.
- Calling Core Tables in Custom SQL – As you customize your solution, you will probably find yourself in need of at least a few database calls. One thing to remember here is that when calling custom entity tables built by Dynamics (at least in Dynamics 2011 since that is what I am currently using), make sure that you are using the SQL Server view that Dynamics created and not calling either the base or the extensionbase tables directly. Dynamics 2011 builds the entities from those tables, and the SQL Server view will be a much better source of relevant data. This is important to remember if you are looking to create a relationship between your entity and another. Targeting the entitiybase and entityextensionbase tables directly mean that you may not always have the linked information for which you are querying. The SQL Server view is a much safer way to pull this information when linking to core tables, as it will contain the information that Dynamics is using to create its relationships.
- Using the SDK – Don’t overlook just how much is included in the SDK. While most of my experience has been with Dynamics CRM 2011, I know that the 2013 instance of the SDK is a bit more tightly interwoven with Visual Studio. In either case, the templates and tools included in the SDK will probably do more for your understanding oh how to work with Dynamics then just about anything else.
Again, not a huge list, but hopefully it will provide a few pointers or reminders that will help you out. I know keeping these things in mind has certainly helped me, but having a strong team to lean on has been the larger help. When all else fails, reach out to your team if you have one and if not reach out to the community.