What is Salesforce?

Salesforce is not a CRM. A CRM is the first thing most companies buy from it, which is a different sentence — and mistaking one for the other is why so many orgs end up fighting the platform instead of building on it.

What you are actually logging into

When someone says "we use Salesforce", they usually mean Sales Cloud: accounts, contacts, opportunities, a pipeline report. That is an application. Underneath it is a platform — a database, a security model, an automation engine and a UI framework — and Sales Cloud is one app built on it, using the same tools you get.

This matters immediately. Every custom object you create sits beside Account as an equal. Every automation you write runs in the same order of operations as the automation Salesforce shipped. There is no "real" schema underneath that you are decorating.

The org is the unit of everything

An org is one instance: its own data, its own users, its own configuration, its own limits. Not a workspace, not a tenant folder — a complete, isolated copy of the platform with your metadata in it.

Almost every confusing thing about working here follows from that. You cannot query across orgs. Configuration does not sync between them. And because your production org is where the business lives, you do your building in a different one and move the changes over — which is the whole reason deployment exists as a topic at all.

The three you will meet

Configuration is data, and that changes everything

When you add a field in Setup, you are not running ALTER TABLE. You are creating a metadata record — a row describing a field — and the platform renders the UI, the API, the validation and the audit trail from that description.

That is why a field you added by clicking and a field added by a deployment file are the same thing, and why "clicks versus code" is a false choice: both produce metadata, and metadata is what moves between orgs.

1
2
3
4

<CustomField xmlns="http://soap.sforce.com/2006/04/metadata">  <fullName>Region__c</fullName>  <type>Picklist</type></CustomField>

That file is the field. Nothing is generated from it at runtime and nothing else defines it.

Why the limits exist

Your org shares hardware with thousands of others. That is what makes it cheap, instant to provision and always upgraded — and it is why your code runs inside governor limits: 100 queries per transaction, 50,000 rows, 10 seconds of CPU.

Those numbers are not a performance target you should aim near. They are a circuit breaker that stops one tenant taking the pod down, and hitting one throws an exception rather than running slowly. Every technique in the rest of this course — bulkification, selective queries, asynchronous work — is a way of staying comfortably under them.

Where this goes

Next you will create your own Developer Edition org and find your way around Setup. After that, the data model: objects, fields and the relationships that make SOQL make sense.