What is customization? How does it differ from configuration? At what point will you need developers, if at all? Who is going to transform the out-of-the-box implementation into a solution that follows your business flow?
In my opinion, the extent of customization required, budget, and your current corporate resources will likely be the most significant influence in your final decision.
Code or No Code
Both Salesforce and Microsoft make the distinction between administration/configuration and development in certification examinations. These exams give a clue as to the direction of both companies. Unlike Microsoft, Salesforce blurred the lines and the developer certifications really did not test a developer’s understanding of coding. Salesforce changed this significantly in late 2015 by introducing a new set of certifications on both the configuration and development sides.
Why is this important? It underscores a fundamental Salesforce goal – do more with no coding at all.
While this is a gross simplification of reality, let me share with you an explanation I routinely give to clients comparing the two platforms:
“If you are willing to accept the Salesforce interface and approach, you can achieve 80% of your goal with no code. Dynamics can get you about 50% of the way.”
This 30% represents a huge gap. Even if you intend to do some coding regardless of the environment, the less a developer is involved the more savings you realize.
Validation
Recall in my “Wrapping it Up” post I mentioned that a decision should not be based on the presence or absence of a feature. Validation is available in both platforms, so this is not a question of “have or have not.” In this instance, it is how validation is implemented.
I chose to focus on validation because it so eloquently demonstrates the fundamental differences between the two platforms.
Salesforce includes sophisticated “no code” validation formulas that activate when a record is saved. For example, the value in a field might be contingent on the values of other fields on the form, fields in a parent record, the particular user, etc.
Dynamics is limited to static validation such as acceptable numeric ranges or whether a value is required. In order to duplicate the flexibility in Salesforce, a developer must write JavaScript or “plug-ins.” For even simple validation rules we are faced with testing, deployment, versioning and storage of source code. This quickly evolves from a 10-minute administrator change into a development process that, done correctly, could take days.
However, nothing comes without a price.
Static versus Dynamic Interface
I recently discussed this topic in a post entitled Introducing the Static Interface. This details the pros and cons of a “what you see is what you get” platform.
In contrast to Salesforce, the Microsoft platform behaves as a typical client-side application even though it is hosted in a browser. The interface is dynamic. As the user leaves a field, Dynamics can show/hide other fields and sections, populate data, do instant validation, etc.
Salesforce, out of the box, cannot. All validation and data manipulation occurs only when the record is saved. In order to override this experience a developer is required, and it will likely be more work than what would be required with Dynamics.
Is this a significant issue? It could be. The post referenced above deals with a “clean and simple” implementation that requires little training. In this case, Salesforce is a perfect fit. And, while it is always preferable to keep forms simple, there are times when this flexibility is an absolute requirement.
Can this be accomplished in Salesforce? Yes, it can. Typically a Visualforce page is employed for this purpose as discussed in this post.
While this is quite simple for the intermediate Salesforce developer, the code language is proprietary and may be more difficult for your generic developer to master than a ubiquitous language such as JavaScript.