Salesforce - An Overview of the Inside

Introduction

Salesforce is a daunting piece of software when you come to face it for the first time. And, although there
are many articles that explain each part of it in great detail, there is a paucity of articles that deal with the
big picture. This post is an attempt at explaining how it all works together.
The Overall Architecture

The following image gives a view of the Salesforce system as implemented on the Salesforce servers.


At the lowest level is the hardware in the data center - the servers, networks, storage etc. And equally
importantly, at this level is the monitoring of the hardware to guarantee almost 100% up-time. Large teams
of technical people work round the clock to keep the servers running.

The next fundamental piece of Salesforce (without which nothing could exist) is the database. There are a
number of notable aspects to this database. Firstly, it is hosted in the cloud. There is only one database that
is shared amongst all the companies that use Salesforce. Secondly, it has a flexible schema - entities and
relationships can be created at will. This is really what makes it possible for Salesforce to be so
customizable.

Sitting on top of this database is Force.com - the platform that is exposed to the world for developing
custom applications on Salesforce. This is the heart of the system and most of this post is concerned with
Force.com

Finally, the applications that end users see and use sit atop Force.com
Tenants
A central concept with an SaaS based system (and Salesforce is no exception) is the idea of multi-tenancy.
When a single installation of software is used by different customers, the data for each customer is
separated from every other customer at a fundamental level. This fundamental unit of separation is referred
to as a tenant.

Users, as identified by their user ids and passwords are uniquely bound to their tenant. When a user
provides his or her credentials at a login page, the tenant to which the user belongs is identified and all
further actions take place within that tenant.
VisualForce
The user request that initiates the display of the Salesforce application actually follows a complex path. The
request goes to a Visualforce page that represents the application that the user sees.

The visualforce page is an xml file which contains a specification of what is to be displayed to the user. For
example, the familiar tabs that you see on the top of a Salesforce page, are described in this xml including
the order in which they should be displayed. The xml describes what to display and where to display it. As
a part of the overall processing, this xml will be used to construct the HTML that is eventually sent to the
browser.

This separation of the UI into a specification and the actual HTML generated from the specification is what
allows the UI to be changed at will. When a Salesforce administrator changes elements in the UI, what is
being changed is the xml specification.
How It Works

The image below show the overall flow of control within Salesforce.com

What is displayed on any Salesforce screen is a representation of the data stored in the database. Consider a
screen showing a list of contacts. A contact is a record in the database and it is also connected to several
other records like the Account to which it belongs and so on.

A visualforce page that shows the list of contacts is an xml file providing a specification of what is to be
displayed. Apart from the tabs at the top and other embellishments of the page, it contains a specification
saying that the list of contacts visible to the logged in user should be displayed in the central area of the
page.

When a user request is received to display this page, the Web Server invokes the Force.com component that
processes visualforce xmls and asks it to process the request. The Force.com component reads the
visualforce specification and when it comes across the specification for listing contacts, it invokes another
Force.com component that is responsible for dealing with objects persisted in the database. The database
related component executes all the required database queries to obtain all the contact records accessible to
this user and returns them to the caller as Contact objects.

When all the Contact objects are available, the visualforce processor loops over them and generates the
HTML representing the table showing the list of contacts.

The generated HTML is sent back to the browser and the user sees the screen with the list of Contacts.
Licenses, Editions, Organizations and Tenants
There is a lot of terminology here and many terms refer to the same things. So here is an attempt at
clarifying some of them:

When you first approach Salesforce, you need to have access to the system. There are many ways to get
access to Salesforce. Of course, the first thing is to have a tenant. A tenant is also known as an
organization in Salesforce.

There are many options for purchasing Salesforce organizations (tenants). The options are related to
features that you can use, the objects available, the storage and other limits. The different options available
in terms of features and pricing are referred to as editions.
For $5 per user per month, you will get access to a tenant that features contact and lead
management but limited to 5 users total - this is the "Contact Manager Edition"
for $25 /u/m you will additionally get access to opportunity management also limited to 5 users
total - this is the "Group Edition"
for $65 /u/m you will get access to the full Sales Cloud CRM system which includes email
campaigns and also unlimited number of users - this is the "Professional Edition"
However, if you want customization, the minimum you will pay is $125 /u/m - this is the
"Enterprise Edition"
for unlimited access and customization you will pay $300 /u/m - this is the "Performance
Edition"
A tenant / organization that is paid for is referred to as a production environment. Associated with a
production environment that can be customized, there is a sandbox environment (described further later).
Additionally, there are two ways to get a free tenant:
1. by creating a developer edition account
2. as a Salesforce partner (e.g. ISV), creating a test organization which also is a developer edition with
more data and more users

A developer edition tenant (organization) is also called a "Development Environment". These tenants are
limited in scope. They cannot be used for production data. They have limits on how much data can be
stored within the tenants. There can be only 2 users within a developer edition account and for partner
accounts there can be up to 20 users. However, these accounts are meant for development and testing of
custom apps and other customization.

Each user within your tenant represents a license. So, if you decide to purchase the lowest priced option for
two users you will pay $10 /u/m and what you will get in return is a tenant of your own and also have two
user ids for that tenant. You can create as many leads and contacts as you like and the data of these two
users will be separate so that each user can track his or her own leads and contacts.


Sandboxes
When performing customization of Salesforce, there is a logistics problem. Let's say that a particular
customer has a customizable production account and wants to have some customization of features. Let's
say, that in addition to the standard features, an HR system for appraisals needs to be added. This will
involve new objects, new relations, new user interfaces, new workflows and so on.

Development within Salesforce is a large project. A "consultant" will gather the requirements and define
the specifications; "developers" will write the necessary code; "administrators" will change configurations
and set up workflows etc. This represents a lot of change.

Obviously, this cannot be done on the production instance as it would disrupt normal operations. There are
two alternatives - do the development on a developer edition or do the development on a sandbox. Actually
a combination of both the alternatives is used.

Developers will develop their code and perform testing in their developer editions. However, the developer
edition is quite different from the production in terms of the configuration where the administrators may
have set up workflows and changed user interfaces. To see how the new development is going to fit into the
actual production version, you need a sandbox.

A sandbox is a replica of the production environment except that it only has a subset of the data and is
completely separated from production. Once customization and development works perfectly within a
sandbox, it can be migrated to production.

The access to sandboxes is separated by using a different URL for logging in: test.salesforce.com. The user
id determines the tenant.
Salesforce Portals
When you purchase a tenant from Salesforce, you get user ids that can access the Salesforce application. In
addition to this, Salesforce provides access to two other sets of people who might benefit from the access:
Partners and Customers. The access is provided through what are called portals: Partner Portal and
Customer Portal.

These are special applications with different features and different levels of access. The customer portal is
intended to be used by your customers. So, lets say you run a jewellery store, and you have high value
customers. The customer portal would be useful for such valued customers to see their history of purchases
or service calls or returns etc. They can only see their own data.

The partner portal is intended to be used by your partners. So, in the case of the jewellery store, you partner
is a jewellery shop in another city who is carrying your goods. In such a case, the partner portal allows
sharing of leads and other collaboration.

In fact, Salesforce, the company, has its own tenant which it uses for its CRM processes. This tenant uses
the Partner portal to collaborate with Salesforce partners like ISVs and others. Of course, the Salesforce
partner portal allows things like creating test tenants which normal partner portals wouldn't.