Deep dive into Salesforce

To the question “What is Salesforce?”, there’s a short and simple answer. Salesforce is a Customer Relationship Management (CRM) system that consolidates all essential customer information in one place, thereby enabling comprehensive management of customer relationships.

That’s exactly what I often say when I’m asked about it. Just to be sure, I might throw in a few practical examples too. Salesforce compiles information about things like key customer contacts, communication across different channels, and of course, completed deals.

The data residing in the system enables real-time tracking of sales targets and, for instance, forecasting the results of the upcoming months.

These examples usually help the inquirer form a sufficiently clear picture of Salesforce. This is based on the assumption that the inquirer is not particularly versed in information systems and does not feel the need to understand what happens under the hood of the system.

Not just one product

In the introduction, the posed question can be answered much more profoundly. In this text, I aim to provide as exhaustive an answer as possible. The kind of answer I would give to an engineer interested in technology. To someone who wants to understand how the Salesforce system truly operates.

A person interested in technology might not necessarily be eager to hear about sales pipelines or a 360-degree customer view. Instead, they’re likely more fascinated by data models, databases, interfaces, communication paradigms, programming languages, and software frameworks. Essentially, an engineer wants to know what Salesforce is – not what is done with it. And that, after all, was the original question.

First off, it’s important to point out that Salesforce isn’t just a single product, but in actuality, an extensive collection of various products and services that the company has amassed and developed over the years.

Depending on the case, these have been integrated into the CRM solution offered as Salesforce’s core business, or in Salesforce’s own terms, the Sales Cloud.

In this context, it’s a must to mention that from a client’s perspective, Salesforce’s comprehensive offerings are really fantastic because you get solutions for all your needs from the same counter, and all the data is also in the same environment.

Basics of cloud services

Now, onto the main point. Salesforce is a cloud service, which naturally often sparks discussions about the definition of the cloud itself.

One of the foundational pillars of the original cloud, known as IaaS, is the scalability and elasticity of resources. Salesforce environments have traditionally been run on a multi-tenant basis, meaning that individual servers are used by multiple clients. This means that the server’s resources are shared across several Salesforce environments. The ability to influence the resources allocated to an individual environment, such as the number of API calls, memory, or CPU cores, has been very difficult or impossible.

There is, however, a reason for this, and I will return to these constraints a bit later.

Customer environments, that is, the system environments of organizations using Salesforce, were for a long time operated in Salesforce’s own data centers. Recently, they’ve been massively shifted to Hyperforce, which essentially means outsourcing the IaaS layer to AWS, and potentially later to other public cloud service providers as well.

For users, the biggest advantage is the opportunity to bring the company’s data physically closer, thereby complying with local data storage regulations. Technically, this also enhances the ability to offer scalability and elasticity to customers in the future, as previously mentioned.

One downside that has been noted is the inability to guarantee Salesforce’s IP space anymore. Previously, third-party systems could filter incoming traffic using a list of allowed IP addresses and/or ranges (IP whitelisting). After switching to Hyperforce, one must settle for filtering traffic by domain name (Domain whitelisting).

In any case, by outsourcing the IaaS layer, Salesforce can better focus on being the world’s largest enterprise software provider, while leaving the responsibility of managing the security of physical data centers, energy supply, and other maintenance issues to others.

A pioneer in SaaS services

Salesforce is a trailblazer among SaaS services, often referred to as the world’s first platform built from the ground up as a SaaS. Its success can be attributed to this fact, as since 1999, Salesforce has had a significant head start and ample time to develop its offering into something effective and reliable.

What’s particularly delightful about leadership with Salesforce lies in its adaptability and the vast range and quality of tools available. The necessity for this is crystal clear, as a SaaS service focused on managing customer relationships and other business operations simply can’t meet the diverse, distinct needs of every organization straight off-the-shelf. Therefore, it’s only natural that Salesforce also serves as a PaaS platform.

In addition to Salesforce being available as a SaaS model that you can start using with just a few clicks, the Salesforce Platform (formerly Force.com) also offers the possibility for highly flexible and impactful customizations. You can modify the system in two ways: with clicks or with code. By ‘clicks’, I refer to no-code and low-code development, while ‘code’ pertains to traditional text-based programming.

Often, a bit of both is required. At twoday Biit, we have, by the way, divided the titles roughly according to this division. A Salesforce Consultant primarily configures the system using a no-code/low-code approach, while a Salesforce Developer handles the necessary coding. However, our team is quite ambitious in practice, so many consultants also produce code, and developers effortlessly click the needed fields or layouts into place. That’s what you get when you try to pigeonhole people.

A maintenance interface on top of the database

Let’s now move on to examining an individual Salesforce environment. From a technical standpoint, and greatly simplified, there exists a web server and, behind it, a relational database. Salesforce has constructed a maintenance interface on top of this database, making it extremely easy to create new database tables, or in Salesforce’s terminology, objects.

Likewise, customizing the user interface view used for inspecting records, such as rearranging fields to desired locations, is extremely straightforward.

Using Salesforce – put simply – largely revolves around the lifecycle of records. A record is created, it might be modified, and eventually, it might be deleted. All of these can occur through user actions, automatically, or based on input from an external system. Moreover, each of these can trigger their own automations. So there you have it, the basic principles of Salesforce explained for an engineer. Pretty straightforward!

For example, the Web-to-Lead functionality automatically sends a new lead into Salesforce when a potential customer fills out a form on the company’s website. The creation of a Lead record can trigger a configured low-code (Flow) or coded (Apex) trigger, which, according to the designed logic, enriches its data using an external business database service or creates a ticket in the customer service queue if needed. Frequently, the lifecycle of a Lead record ends with its conversion into a contact or customer account.

A flexible and user-friendly database enables the rapid expansion of Salesforce for almost any application. For instance, if a business focuses on selling or renting properties and real estate, Salesforce can easily incorporate new tables named Property, Real Estate, and Apartment, along with the necessary fields and references to other tables. Adding such functionalities to traditional, long-constructed software tends to be extremely labor-intensive and time-consuming.

Different cloud services for different purposes

Over the years, Salesforce has significantly expanded its offerings and named solutions suitable for different purposes as their own cloud services, even though sometimes it’s just about switching on functionalities that exist on the same platform.

The original CRM is called Sales Cloud, and it includes basic objects such as Lead, Opportunity, Account, Contact, Contract, Product, Pricebook, and so forth.

Service Cloud is specifically designed to boost customer service, Marketing Cloud caters to the needs of marketing, and Commerce Cloud is for building e-commerce platforms. Experience Cloud (formerly Community Cloud) enables the creation of customer and partner portals.

From a database perspective, the former Salesforce IoT Cloud and the current Data Cloud are also services of great interest, dealing with genuinely massive amounts of data in real-time. For instance, IoT sensors can feed their readings at such a pace that the standard Salesforce relational database simply isn’t cut out for such heavy-duty use.

The IoT Cloud had indeed built its own platform called Thunder, utilizing building blocks familiar from big data circles—Apache’s open-source components. In Thunder, Storm handled the data streams, Kafka acted as the messenger, Spark as the analytics engine, and Cassandra served as an ultra-fast NoSQL database. However, the IoT Cloud was discontinued in 2021. Similarly, in the Data Cloud (formerly known as Salesforce CDP and Salesforce Genie), there is a proprietary data lakehouse-style repository that combines the best aspects of data lake and data warehouse technologies.

A package that stays together easily

How does Salesforce manage to keep things so tightly knit? Many who have used IT systems for a longer time have surely experienced those moments when a spreadsheet, drawing program, or some other application first freezes itself and then eventually the entire computer.

Despite occasional minor delays, Salesforce has nevertheless succeeded in creating an environment that can be customized and programmed without ending up constructing a perpetually stumbling bloatware, which can be considered an excellent achievement.

Salesforce keeps individual customer environments in check through platform limitations. These restrictions ensure that no customer environment can consume excessive resources, such as computation time, memory, or network traffic.

If a programmed execution consumes too much memory or takes too long, the platform simply terminates the execution. In such a scenario, when one looks under the hood, the programmer can see what kind of exception occurred and modify the code accordingly to ensure that the execution happens within the platform’s limitations.

Platform limitations are crucial, especially in a multi-tenant environment, to ensure that different customer environments remain performant independently of each other. However, I consider an equally significant benefit to be that they prevent one from modifying the environment to the point of unusability.

From a programmer’s perspective, limitations manifest as Salesforce’s specific requirements when planning a new implementation. A simple solution often has to be crafted in a more complicated manner due to these limitations. A significant part of a Salesforce programmer’s job focuses on circumventing these platform constraints, and an experienced programmer will account for these limitations right from the planning stage. Considering the benefits achieved, this is, however, a good compromise.

In addition to the aforementioned aspects, Salesforce is of course much more. Many points were left unmentioned in this writing, and several technically intriguing services and technologies were not mentioned at all. Each Salesforce product could be discussed in multiple paragraphs. At the very least, Einstein, Tableau, and Heroku deserved a mention. Similarly, an entire article could be dedicated to Salesforce’s programming languages. Perhaps next time.

I hope I have managed to enhance your understanding of Salesforce from a more technical perspective. With Salesforce, like many other companies, when you seek information about new services, you often encounter a scenario where the product presentation is made up of cheerful images, marketing materials, sales pitches, and buzzwords.

I’ve found myself longing for more fact-based content that delves into the technical aspects of the service and the components used in the background. From the get-go, twoday Biit’s mission has been to fuse business acumen with technical expertise. We speak both languages with our clients, business or IT.

Hannu Järvinen

Hannu Järvinen is a technical architect who works as a CTO at twoday Biit. Hannu specializes in implementing technically challenging solutions, including IoT services and customer-specific applications.