At some point during the development lifecycle of mid-to-large scale Dynamics CRM projects, we are faced with a number of design decisions that are to be made. That is, when is it appropriate to customize the platform versus when is it appropriate to opt for pure configuration.


First off let’s talk about what configuration is. Configuration in the Dynamics CRM sense, refers to the ability to use out of the box (OOTB) functionality to achieve a desired result. For example, using business logic features such as CRM Workflows and Business Processes, or CRM Form Designer for user interface design. These are no-code configurations where no specific custom programming logic is required.

Next up we have customisations. Customisations or sometimes referred to as CRM extensions can range from simple through to complex customisations requiring custom coding or development using the CRM SDK. This is not to be confused with CRM terms such as Custom Entities (which are in fact configuration of the data model), but actual business logic that are self-contained extensions either developed using JavaScript/C# or even straight SQL (for on-prem deployments).

There are hard-costs and soft-costs for opting for one over the other. And the factors which lead to choosing Customisation vs Configurations can be either Technical or Business driven. Here is a check list of factors which deserve some consideration when opting for one over the other (in no particular order of importance).

  • Time constraints

Where there are immediate time constraints brought on by resourcing or an external factor, this lead to a decision to bring forward shippable product releases by opting for pure configuration. One of the drawbacks to this approach is fidelity in the user experience or functionality is sacrificed, however that may be outweighed by other considerations that will be mentioned later in this article.

  • MVP and The Value Proposition

Creating a minimally viable product (MVP) is a way of bringing forward ideas and testing concepts early. This is agile thinking and places emphasis on features that bring the most value to the business/customers. A MVP in a CRM context places a certain emphasis on achieving quick wins through using OOTB form controls over custom developed form controls – where an investment is required to develop custom controls whereas the investment in using an OOTB form control is negligible. An MVP is an excellent way of ascertaining the level of user acceptance of the product early on.

  • Tie back to requirements

The best place to start is with the original business requirement. Ensuring that the project has not deviated from the original intention of our user story. A differentiation between want vs need should be made at this decision juncture. On large projects, a degree of segregation of roles can sometimes lead to a misinterpretation of the original requirement and subsequently lead to some less than desirable design decisions. It is worthwhile clarifying the original requirement, possibly develop an OOTB prototype to test the proposed solution with the business.

  • Platform improvements

When opting for an extension to the platform, we should always keep in mind that Microsoft is continually investing in the Dynamics CRM platform. This is especially so for on-cloud deployments which we will talk about further in this blog. Major releases (such as 4.0, 2011, 2013, 2015, 2016) as well as mid-cycle releases (2016 Update 1) have introduced new features which may or may not be code compatible with any custom extensions. One way to guard against using unsupported extensions is through the use of the Microsoft CRM Custom Code Validation tool, which detects any deprecated code references and offers solutions for a fix. However this method is not completely fool proof, with certain operations likely to be deprecated with no alternatives.

  • Online CRM / Sandbox

Another consideration is any future plans to move between cloud and on-premise environments. While the best solution designs are largely hosting agnostic, it is wise to ensure that any customisations to the platform are using supported code and that all plugin and workflow logic run in a sandbox mode. This will allow portability of the solution if at any point the business chooses to move their hosting to the cloud.

  • Integration requirements

Any hard integrations are likely to be through the CRM SDK (typically through manipulating data within the CRM Data Model or pushing data back to other line of business systems). Integrations almost always require a degree of programming logic, however there are tools such as Scribe or KingswaySoft that enable CRM awareness of the source/target systems. Efforts to minimize integration efforts should always be evaluated.

  • Supportability

The issue of supportability will likely come up, and the original development team may or may not be available to field queries about the construction of the solution. Clean customization code will enable better supportability, and any configurations that are made should always be well documented. The higher the degree of customization (typically quantified by lines of code) the higher the support requirement is should something go wrong.

  • Third Party Components

As mentioned earlier, with the availability of tools that make integration easier, there are also many third party components and connected cloud services which integrate easily to CRM. A cost benefit analysis should be made, for example in a project where there are many dozens of templated custom mail merge documents it may be worth investigating the use of a CRM Document Generator such as Xperido. Reasons for choosing a third party component may include product maturity, premium third party support, as well as lower development and internal support costs.

Well hopefully this information has been of some benefit to you, please drop me a message if you have any questions or comments in the box below. Thanks for tuning in, until next time.