Salesforce CRM

Introduction

In this article I plan to provide a high-level overview of the three main modules (Salesforce calls them clouds) of Salesforce CRM and then proceed to explain the key entities (Salesforce calls them Objects) that play a crucial role in each of the three clouds. I will then end the article by providing analysis in assisting you with your make-or-buy decision.

Architectural Overview

Salesforce has three main modules - Sales cloud, Marketing Cloud and Service Cloud. There are many other modules (clouds) available from Salesforce but the most widely used one is “Sales” cloud. Salesforce also provides Platform as a Service (PaaS) thought Force.com and Heroku, the latter is a company it acquired. Force.com is the platform on which all clouds (modules) of Salesforce are build. Heroku is a true PaaS that allows developers to deploy their applications written in languages like Node, Ruby, Java, PHP, Python, Go, Scala, or Clojure into its managed containers without worrying about the underlying infrastructure.

NOTE: The reason I call Heroku a “true” PaaS is because Force.com is useful for Salesforce cloud customization and everything Salesforce related. Heroku is not.
The Force.com platform has gone through some architectural changes from its “Classic” version to its “Lightning” version. As shown in the diagram, in the classic model, Salesforce used a Model View Controller (MVC) pattern to allow custom web pages to be built utilizing Visualforce, Apex classes and Salesforce objects. The design was more page centric, later they came up with a component centric design approach and gave a new fancy word to it called “Lightning”. This approach is basically based on Model Controller-Controller View (MCCV) pattern. The component centric approach allowed the same component to be reused across multiple pages. In Lightning, as shown in the diagram there are two controllers one on the client-side (written in JavaScript) and another on the server side (written in Java like language - apex classes). The latter is your classic style controller. Having two controllers allows Salesforce to change the client-side framework independently of the server-side framework and utilize SOAP/REST API for exchanging data, thereby providing architectural decoupling. Since the data exchange occurs behind the scene the user interface is not rendered on browser or phone “apps” every time an action is performed by the user on the screen there by providing a more responsive UI experience (hence the term Lightning, which by the way is what any Single Page Application framework does)

Key Objects in Salesforce CRM

A few observation points about the above diagram

The CRM process flow shown in the diagram provides you with key Objects that are heavily used within Sales and Marketing cloud. There is a lot of functionality overlap between the two and as such Marketing and Sales go hand in glove in any organization so its obvious Salesforce ended up with overlaps as well. The blue arrow flow in the diagram is my way of showing how the process flows in a CRM application, which is

• We start with Campaigns – like trade shows, email reach out, Webinars etc.
• These Campaigns may result in potential Leads
• Some Leads will get converted to Opportunities and when that conversion occurs you can create other entities like Contacts, Accounts etc.
• When Opportunities are won, you can create Contracts

The above bullet points is pretty much the meat of the two clouds (Sales and Marketing)

The Service cloud is typically used for IT service management (ITSM) and provides capabilities like

• Opening a Case
• Tracking the various stages a case goes through until it’s resolved.
• Using Solutions (with Classic) or Knowledge Objects to categorize resolutions and Issue/Article types which can then be used by your help desk staff personnel’s for resolving similar Incidents in future, basically to provide a Knowledge base. You can then use the Knowledge base like a “google” Help Desk search engine.

NOTE: Coming from object oriented and database designing world, I am uncomfortable calling Entities and Classes as “Objects”. In my mind, objects are class instances but Salesforce uses the term Objects to mean Entities and Classes.

Make-or-Buy Analysis

The above flowchart will help you determine when you should use any CRM system like Salesforce as a SaaS versus building it from ground up.

A few observation points about the above flowchart while you decide which way to go

If you are a small size company that does not plan to use developers in the long run beyond the initial setup phase then you should go for Salesforce CRM or any other competing SaaS CRM software. When you do go in that direction make sure that you do not customize the CRM software using programming capabilities of the software, instead try to customize through configuration (declarative) changes provided by the Salesforce Admin pages (Setup), so basically what I am saying is use things like Validation Rules, Page Layouts, Profiles, Workflow Rules (for classic), Process Builder (for Lightning), Approval process etc. versus custom coding with Visualforce, Apex Classes, Triggers, Controllers etc. In a nutshell, try to change the business processes in your company to adapt to what Salesforce provides out of the box without having a need to custom code. Do not do custom code - just speak with other people about their painful experiences (cost wise) in converting Classic-style custom code to Lightning-style equivalent. By avoiding custom code to begin with, such drastic changes done by Salesforce will have minimal to no impact on your migration path thereby avoiding the need to have developers.

NOTE: With classic you will typically need developers who come from Java/JEE background. For Lightning you will need developers with Java/JEE background as well as developers who are very good with JavaScript. So you see how this defeats the purpose of SaaS. Especially for a small sized company. Hence I suggest no custom coding.

If you find yourself using developers to constantly tweak the salesforce platform using custom coding options (like Apex classes, Controllers, Visualforce, Lightning App Builder etc.) provided by Salesforce then I truly believe you are better off custom building your own CRM application that will save you money in the long run and here is why –

• Physical datacenters are disappearing and are getting substituted with  Cloud providers like AWS, Azure, GCP and each of these cloud providers provide Infrastructure As Code (IaC) capabilities that allow you to build data centers in a matter of minutes using templates. Point is – it’s much easier for companies to manage data centers these days with IaaS than it was in the past
• Salesforce is heavily Java like in terms of its custom coding capabilities and you will end up with Java developers working for your company if you do too much customization to the Salesforce platform. So why not ask the Java developers to build your CRM, you saw how simple the CRM process flow is in my earlier “Key Objects in Salesforce CRM” section, I believe you can built your own CRM with a team of 3-5 developers within 6-8 months’ time period (or at least get most of the functionality built). 
• Salesforce uses MVC pattern for classic version and MCCV pattern in Lightning. Both these patterns are widely used in software designing. They are primarily used to avoid ripple effects from changes in any of the three layers - the Presentation (View) layer, Business (Application) Layer and Data (Database) layer. These patterns are also widely used in modern day application programming languages/frameworks like ASP.NET MVC (C#), Java (JEE), Django (Python), Ruby on Rails, NodeJS etc. 
• There are many UX/UI application frameworks (React/Redux, AngularJS, Ember, Meteor, Vue etc.) that allow you to build Single Page web applications in shorter time period than before. My point is – application development is not how it used to be in the “dotcom” era, a lot has changed over the years and rapid application development is truly possible these days with advancements made in software development and more specifically these application frameworks are becoming more stable and mature as time goes by.
• With cloud providers giving NoSQL services (like DynamoDB, Azure Cosmos DB, Cloud Bigtable, Cloud Datastore), managed relational services (like RDS, Redshift, SQL Database, SQL Data Warehouse, Cloud SQL, BigQuery) and Big data services (like EMR, HDInsight, Cloud Dataproc) it’s easier than before to manage and scale data.
• The technology you pick behind your custom built CRM application framework changes at a faster pace than Salesforce and you will be able to perform upgrades much faster than Salesforce giving you the competitive edge over others who are using Salesforce for their CRM platform – very key differentiating factor to win new customers. 

Conclusion

I hope this article was helpful. My intent in the Make-or-Buy analysis section was to convey the point that if you use a CRM software “as is” with no custom coding then you get the biggest return for your investment otherwise you are better off with home grown equivalent.