I recently worked on a Dynamics 365 RFP, and I noticed how many are not in agreement with defining the difference between OOTB vs Configuration vs Customization vs Third Party tools. I had to survey and ask some friends and previous colleagues what they consider configuration and customization, and again I noticed some debates.
Then, I googled the topic in the context of Microsoft Dynamics 365 and found a partner post explaining the difference nicely. I also found many other posts, one of which, https://www.solzit.com/dynamics-crm-customization-and-configuration/.
I can say that I didn’t find a 100% clear answer that everyone agrees on. Therefore, in this post, I will try to understand the difference between OOTB vs Configuration vs Customization vs Third Party.
The diffrence between OOTB vs Configuration vs Customization vs Third Party tools
Before answering the difference between each, we need to agree on the importance of drawing the border between OOTB vs Configuration vs Customization vs Third Party tools. Generally, identifying to which pocket the RFP requirement belongs helps us accurately calculate the effort and estimate the cost of that functionality.
My understanding was that anything that belongs to a solution under the customization tab in the “System Administration” and requires a user with “System administrator” or “System customizer” roles is considered a customization.
However, my understanding of the difference between OOTB vs Configuration vs Customization vs Third Party tools might not be proper. Honstly, I am still convinced with this explanation, but I will be going with the general understanding, as below.
Best differentiating rule
The best explanation I got was that the difference between configuration and configuration is when we must write code, even low-code.
My valuable colleague told me that Dynamics 365 is equipped out of the box to build custom tables, add custom fields, and add custom forms and views. So, none of these is considered customization.
He told me that customization is when we cannot achieve our client’s goals using a Dynamics 365 built-in tool, and we will have to use a code. “Even low-code, low-code is still code!” he explained.
I want to build a table to list all the actions we can do, such as creating tables, charts, views, forms, etc. But I don’t think I should set standards that many people debate.
Out of the box
Out of the box (OOTB) are all the built-in features and functionalities of Microsoft Business Application that works immediately without any need for writing code, configuring, or customizing the solution. These features are thoroughly tested and configured by Microsoft to serve users natively.
A straightforward example, If the requirement wants to convert a lead into an opportunity. This function is an existing OOTB function that the organization will get on day one. Nevertheless, they might need to tweak it or build additional views that are possible by configuring the system to match their exact needs.
Configuration features and functionalities are all the modifications and automation needed to set Microsoft Dynamics 365 CE and Business Applications to behave according to the client’s expectation without writing code and can be achieved natively using Dynamics 365 tools. Examples of Dynamics 365 configurations are word templates, email templates, view, forms, dashboards, apps, native portals and many other capabilities. An iterative solution approach using a DevOps system to document, deploy and test the configuration needs to be implemented to ensure that configuration is utilized correctly.
Simply, customization is extending Microsoft Dynamics 365 CE and Business Applications using code to achieve goals that are not possible Out of the Box OOTB or using regular configuration. Examples of customizations are native workflows, plugins and integration with external systems to share data. Documentation, version control, testing and automated testing scenarios are highly needed to ensure successful implementation and adaptation. Also, a DevOps solution following an agile process, such as Azure DevOps, guarantees high performance of the developed solution and continuous development.
Third-party solutions are all software products, service, features, functionalities that are not severed by one of Microsoft Business Applications and is possible to be achieved by an external IT vendor. Extending Dynamics 365 using custom code might be needed to integrate third-party systems. Examples of third-party solutions are external service providers that exchange information with Dynamics 365. Detailed documentation and testing of the integration between Dynamics 365 and the external third party will be provided and performed during the deployment of the third-party system and follow up test in the following sprints. Some of the real-life examples I covered in previous posts are Adobe Sign and LinkedIn Sales Navigator.
Configuration vs Customization
Finally, out of our discussion about the difference between OOTB vs Configuration vs Customization vs Third Party tools, I think that the most crucial distinction that we need to consider is configuration and customization.