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.
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.)
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.