So you think XRM coders are evil? Perhaps you are barking at the wrong tree.

After almost a decade architecting and implementing XRM solutions, it seems a constant theme for me to hear from both clients and project managers, that they want a system where no coding (or very little of it) is desired. I understand what the origin of that is, perhaps, previous past experiences when they had systems that for any kind of change, it required the intervention of expensive developers or maybe the unfounded belief that the functionality required by your system could be addressed by the CRM platform right out-of-the-box.

In the particular case of Dynamics CRM, it’s true that it provides a platform with a lot of power and flexibility and almost endless possibilities in regards to customization. In many instances, clients may even think that they can get by just having a good CRM configurator or a junior developer.

Well, here comes the bad news. If you want a successful XRM implementation, you do need a good solutions architect and one or more good senior developers, and most likely, you will sooner or later need coding (whether you like it or not) if your customization requests are a little bit complex.

The myths or at least some of them

If you rely solely on configurators or inexperienced (often cheap) developers, you will probably end up with a system with some of the following characteristics:

  • Lookup data? I’ll just create an option-set.
    • So, what’s wrong with my option-sets? Actually, nothing as long as you use them appropriately. If you have data that is static and you don’t have any concerns about who can access it, then yes, you can use option-sets for that. However, if your lookup data can change over time or perhaps it needs to expire at some point or you need to restrict certain users from modifying it, you definitely need to use a custom entity. If you have been in this business for a while, I wonder how many times you’ve seen option-set values that need to be retired but can’t because they are in use, and you end up prefixing those values with “ZZZZZ” so that they show at the end of the drop-down?
  • I want to present some fields as check-boxes, therefore, I need several Boolean fields.
    • If you find your entities with numerous Boolean fields that perhaps you even forgot what purpose do they serve or you need to add new ones as your processes change? Then you definitely need to use a custom entity. If you don’t believe me, then try to create a report where you need to group by some of those Boolean fields. In essence, a particular UI requirement should never drive the way the data is structured.
  • I can do anything with workflows.
    • As a rule of thumb, if your workflow goes beyond one screen, meaning that you have to scroll or if you need to use a lot of child workflows or custom workflows, then you need a single custom workflow or better yet plugins. Any doubts about why using plugins is better than custom workflows? Check the Appendix below.
  • Customizations needed? I can get by using lots of JavaScript.
    • If your system has thousands of lines of JavaScript chances are you are either out of compliance (GetElementByID anyone?) or your system needs some serious re-architecting. The fact that form scripting is available and that the SDK offers powerful features, should not change your perception of what tools are the most appropriate for each task. JavaScript is primarily designed for handling UI issues only and should be used just for that. Business functionality almost always will require the use of plugins.

The Appendix

Let’s address the concerns raised previously. What do you do if you need to display lookup data as a dropdown, ergo avoiding opening a new window like Dynamics CRM does OOTB? That’s one of those scenarios where you do need a seasoned developer to perhaps design a web-resource to do that.

The same logic can be used if you need to display associated data (from a custom entity) as checkboxes on a CRM form; you definitely need a seasoned developer to create a web-resource to provide such checkboxes.

Now, why do we think you should favor plugins over workflows? It’s true that nowadays the functionality that you can achieve with plugins and custom workflows is very similar; however, plugins still have the edge since they don’t need to rely on the presence of a regular workflow in order to run.  For example, if you need to change the functionality of a plugin, you just need to make your changes and re-register the plugin. Whereas in the case of custom workflows, if you have to change its signature (i.e. add a new input parameter) you will have to deactivate every single workflow instance that uses it and remove any references to such custom workflow, and that can turn into a major project. Besides, plugins are more granular in terms of where in the event pipeline (pre/post save) you can execute them, plus you have a larger number of events that can trigger them along with those events from CRUD operations (i.e. on retrieve, on associate, etc.)

Finally, why is JavaScript not the appropriate tool for coding business logic? Very simple, because in Dynamics CRM JavaScript can only be invoked from a CRM form event or from an HTML web-resource. So, in case you have a portal to provide external access to your CRM data, or have an integration process with an external system, and if you have some functionality that needs to occur say on creation or update of your data, but you have implemented it only in JavaScript, then that functionality will not be executed in those two scenarios. Copy/pasting is not an option since that would require maintaining a multiple code base.

The reality

Should you hopelessly resign yourself to paying top dollars (for these pesky developers) once your system that is already in production needs to be extended? Well, not necessarily. It all depends on how your system is designed. So here is where a well-seasoned solutions architect comes in really handy. Besides having a design that ‘lives and breathes’ a solid foundation and best practices, your system should be built not just thinking of today’s requirements but also growth and scalability. If you favor a system that can get extended by adding data or metadata over a system where you find a lot of hardcoding, perhaps you may end up with a system that could be extended by your administrator.

Bear in mind that computer systems in general should be considered as owning a car, since most likely you will have to replace (or update) them every five to seven years. And using a well-seasoned solutions/technical architect should be like your tires and brakes, you don’t want to go cheap on them.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s