Salesforce and Microsoft Dynamics 365 are currently the two leading CRM systems on the market. Many people spend a lot of time trying to decide which of these two CRM solutions will provide the highest overall value to their organization.
While Dynamics 365 and Salesforce have a lot of similarities, they also have a number of distinct differences.
In this post, we’ll not only examine what some of these differences are, but also some of the evolutionary reasons behind these differences. This, in turn, may shed some light on why Salesforce continues to have an edge in market share over Microsoft Dynamics CRM.
How Applications Evolve
The current state of any application in terms of features and functionality is nothing more than the result of a series of decisions made by various people within the vendor organization — including executives, product managers and developers — over the course of time.
What were some of the decisions that were made at both Salesforce and at Microsoft over the years and what drove these decisions?
A Blank Slate vs. Available Technology and Interfaces
When Salesforce was a small startup, the company did not have any of its own technology. Salesforce’s development team had to build everything within its application from the ground up, in terms of features, functionality and development tools.
On the other hand, at the time Microsoft decided to develop a CRM application, the company already owned a wide variety of business technology that could be leveraged within a CRM system.
There are pros and cons to building certain pieces of functionality from the ground up versus incorporating existing technology into a new application.
CRM User Interface and Navigation
Salesforce was designed as a web application from day one. As such, there are many design features that are optimized for a browser experience, rather than for a desktop application experience. A minor example of this is the fact that there’s a Save button on both the top and bottom of Salesforce’s edit screens.
Microsoft originally made the decision to include Windows-style drop down menus within its browser-based CRM application. With the release of Microsoft Dynamics CRM 2011, the decision was made to replicate the Microsoft Office ribbon interface within the browser in order to give users a common experience across familiar Windows products and CRM. With the release of Microsoft Dynamics CRM 2013, the UI was “Metro-fied”.
Browser and Device Support
A design decision that Microsoft made early on was to have the application only support Microsoft’s own browser, Internet Explorer. Since IE does not run on OS X or iOS devices, Microsoft at a later point realized that it needed to add support for non-IE browsers such as Safari.
Salesforce, on the other hand, did not have its own browser and therefore based the application’s browser support on customer preferences. For a time, this gave Salesforce a competitive advantage within mixed-browser environments.
An early product decision made by Microsoft was for the application to pop open a new browser window each time a record was selected within the current browser window. Because new browser windows are modeless, there was nothing to prevent a user from opening a large number of browser windows.
Salesforce, on the other hand, designed its application to replace whatever is in the current browser window with whichever view or record is selected within that window. If a user wanted to open a new browser window or tab, they needed to take specific action, such as right-clicking a link and selecting “Open link in a new tab”.
With the 2011 release, Microsoft reduced the number of new browser windows or tabs that open during navigation. However, whether a new window or tab opens upon record selection remains a difference between the applications. With the release of Microsoft Dynamics CRM 2013, new browser windows no longer popped open when a user navigated from record to record.
Upgrades and Updates
With its blank slate, Salesforce took the approach of making upgrades and patches automatic — upgrades occur without customers having to take specific actions. Salesforce switched to agile development in 2006. Shortly after this, Salesforce shifted to three seasonal releases a year (winter, spring, summer).
Each seasonal release of Salesforce adds a host of new features and functionality. Yet with rare exceptions, new releases do not require any preparation on the part of customers.
Microsoft’s traditional approach with its many desktop products has been to release major new versions every few years. One example is that of Outlook 2003, 2007, 2010 and 2013. Microsoft CRM originally inherited this company-wide approach, with a version progression of 1.0 to 3.0 to 4.0 to 2011. In some cases, customers needed to go through a significant upgrade process to move to the next version.
With the 2011 release, Microsoft moved to a more consistent schedule of major releases and update rollups. However, this post implies that Microsoft has not yet reached the point where no action is required by customers.
Salesforce decided to build an application that was multi-tenant on both the application side and on the database side. As such, it selected the most scalable database available at the time, which was Oracle. However, Salesforce had to architect the database in a very specific way that would support multi-tenant scalability and security as well as efficient updates.
At the time Microsoft CRM was being written, Microsoft already owned one of the most popular enterprise databases — SQL Server. SQL Server naturally became the back end database for CRM. While SQL Server is scalable for enterprise needs, a SQL instance is not scalable across thousands of enterprises as is a single Salesforce database instance. Therefore, with CRM 2011 Online, each customer has their own SQL Server instance.
The benefit to Microsoft Dynamics 365 customers is that their database can be moved from online to on-premises and visa versa. Customers can also get a full copy of their database if they decide to leave Microsoft Dynamics 365. However, tens of thousands of database instances for Microsoft CRM Online customers likely represents more maintenance and upgrade overhead for Microsoft compared to Salesforce’s one hundred plus instances.
Microsoft had a pre-developed reporting engine within SQL Server called SQL Server Reporting Services (SSRS). Therefore, the understandable decision was made to use SSRS as the CRM reporting engine rather than create CRM-specific reporting. In turn, Microsoft had to build a level of integration between the CRM application and the reporting engine.
Salesforce, on the other hand, had to build its reporting engine from scratch and then iterate on top of this creation. This has meant that the types of reports that customers were demanding dictated the evolutionary path of the reporting engine.
The two evolutionary paths of reporting have resulted in subtle difference in report design and execution. The following video compares generating reports in each of the two systems:
Here’s a playlist of additional comparison videos.
This is another area in which salesforce.com had to develop functionality from the ground up.
Microsoft, on the other hand, already had a workflow engine called Windows Workflow Foundation (WWF).
Workflow that is designed via the user interface in the respective products has fairly similar capabilities. However, custom workflow activities can be written in Microsoft CRM under WWF.
Extended Customization Tools
Programming tools are another software offering that Microsoft already had in its portfolio at the time Microsoft CRM was created. Extending Microsoft CRM requires Microsoft CRM’s software development kit, which in turn requires Microsoft Visual Studio 2010 and Microsoft .NET Framework 4 or .NET 4.5.
Salesforce created its own extended customization tools — Apex for coding and Visualforce for rendering custom pages and views. Unlike .NET and Java, which allow for designing a wide variety of applications, Apex is purposely limited in scope. Apex is exclusively for building business applications to manage data and processes within the Force.com platform.
While Outlook still dominates as a corporate email client, there are a number of other email clients used in business, including the email client on mobile devices.
Microsoft understandably put a lot of effort into integrating with its own email client, Outlook. Because it owns the email technology, Microsoft has had the upper hand over its competitors in terms of how extensive CRM to Outlook integration is.
Similar to its approach with browsers, since salesforce.com did not have its own email client, it took a more agnostic approach to email integration. Salesforce includes a feature called Email to Salesforce, which allows users to Bcc a special address from any email client in order to attach that sent email to customers’ Lead or Contact records. Users can also forward inbound emails to this special address to associate emails with CRM records.
For companies that are using Google Apps for Business, Salesforce has some basic functionality that allows a Gmail user to initiate a Gmail from a CRM contact record. Salesforce has also embraced a number of third party email integration solutions on its AppExchange, including LinkPoint360, Cirrus Insight, Match My Email and more.
Microsoft already had a wide arsenal of applications and tools that could be incorporated into its own CRM solution. Salesforce found itself in a position in which it had to develop virtually all of its functionality from scratch. These very different circumstances resulted in distinct product differences in a number of important areas.